La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

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

Présentations similaires


Présentation au sujet: "Politiques de sécurité 11 e cours (hiver 2014) Louis Salvail."— Transcription de la présentation:

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

2 Organisation Politique de sécurité Une description simple des objectifs de sécurité dun système et une stratégie de haut niveau pour les satisfaire. Politique de sécurité Une description simple des objectifs de sécurité dun 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. 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. Mécanismes de sécurité Les solutions techniques utilisées pour satisfaire les objectifs. Nous avons traité surtout de mécanismes jusquà maintenant... Nous avons aussi traité des modèles de menaces classiques Nous allons maintenant voir cet aspect important Les objectifs définissent les états autorisés dun système. La stratégie indique comment on compte satisfaire les objectifs. Pour définir les états autorisés dun système, encore faut-il décrire le système sur lequel ces politiques vont sappliquer. Les politiques dépendent déléments de la sécurité des systèmes. Le TCB doit satisfaire une politique bien structurée.

3 Cest quoi un TCB? (base informatique sécurisé) Ex: Le contrôle daccès du serveur WEB est considéré comme une partie du TCB du système qui comprend le serveur UNIX, la navigateur dun usager et lapplication 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 lenvironnement dexé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 dun 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 : aa, Si ab et ba alors a=b, Si ab et bc alors ac. De plus, pour a,b S : Il existe une borne inférieure maximum pour a,b : un c S tel que ca et cb et, pour chaque c avec cette propriété, cc. Il existe une borne supérieure minimum pour a,b : un d S tel que ad et bd et, pour chaque d avec cette propriété, dd. Exemple : S={public, délicat, secret, top secret} publictop secret secrettop secret délicattop secret publicdélicat Exemple : S={public, délicat, secret, top secret} publictop secret secrettop secret délicattop secret publicdélicat Le na pas à être défini pour chaque paire. na pas de borne inférieure maximum pour secret,top secret

6 Les droits daccès comme treillis Une politique de sécurité pour les droits daccès à des fichiers peut être définie avec le treillis : S={aucun, lecture, écriture, lesdeux} tel que : aucunlecture, aucunécriture, aucunlesdeux, lecturelesdeux, écriturelesdeux, mais lecture et écriture ne peuvent être comparées.

7 Deux façons simples dutiliser un treillis 1. Définissons les sujets comme tous les utilisateurs et processus dun système. Il sagit des entités qui peuvent interagir avec les autres parties dun 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 dun objet ou dun sujet r est désignée C(r). Nous pouvons énoncer que le sujet s peut appliquer une certaine opération sur lobjet 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 dun système. Linformation ne peut circuler de a vers b que si ab. Ceci sapplique si la position ab peut être interprétée par b est plus sûr que a et la politique en est une de confidentialité. Pour lauthenticité, ab peut vouloir dire que b est plus fiable que a. Linformation peut alors circuler de b vers a que si ab. Les deux approches ont des similitudes. Les classifications dans un treillis impliquent un flux (des directions de circulation) dinformation.

8 Limportance des bornes inférieures et supérieures Supposons quune 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 linformation quant à lauthenticité : Question : Quelles parties du système admettent que a et b circulent vers celles-ci? Réponse : les parties s telles que cC(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 sagit de définir des niveaux de sécurité : Par exemple : publicsecrettop 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 lobjet o. Deux règles sont alors définies (*-properties) : Pas de lecture en haut : Le sujet s peut lire lobjet o seulement si C(s)C(o). Pas décriture en bas : Le sujet s peut écrire sur lobjet o seulement si C(s)C(o). Lidée est déviter que linformation circule dun niveau élevé vers un niveau moins élevé. Un chercheur secret peut lire des documents secrets ou publics, mais pas top secret! 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 linformation dun certain niveau vers un niveau moins élevé. Linformation circule ver le haut. Modèle assez rigide et difficile à utiliser dans la pratique. Un système peut être dans limpossibilité deffectuer ces tâches, à moins que de linformation 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 laccent mis sur lintégrité. Dans ce modèle, linformation 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 lobjet o seulement si C(s)C(o). Pas décriture en haut : Le sujet s peut écrire sur lobjet o seulement si C(s)C(o). Linformation ne doit pas circuler dun bas niveau à un niveau élevé. Ceci assure que linformation nest pas contaminée avec de linformation moins intègre.

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

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. Linformation 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 quaucune information à propos dun client nest 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 quun sujet s a accès à c si et seulement sil na 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 daccé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 lorsquune 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 quun 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 à larme nucléaire comme montré dans plusieurs films. Séparation fonctionnelle : Certaines actions sont possibles lorsquelles sont autorisées par plusieurs personnes, mais à différents moments. Pour pouvoir se présenter à lexamen, 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 senregistrer.

17 Contrôle daccès Les modèles que nous avons vus permettent la description de haut niveau des règles pour la circulation de linformation et les contrôles entre les différentes parties dun système. Les modèles supposent implicitement que lorsquun utilisateur veut opérer sur un objet, le système peut vérifier lidentité de lutilisateur et déterminer ses droits et privilèges. Vérifier lidentité dun utilisateur peut se faire à laide dun mot de passe, de sécurité matérielle, ou biométrie comme nous lavons vu. Déterminer les droits et privilèges courants est un problème différent. Cest le contrôle daccès.

18 Contrôle daccès En général, les droits et privilèges peuvent être déterminés à partir de lidentité de lutilisateur et de la politique de sécurité. Déterminer laccès sur le moment pendant que lutilisateur attend nécessite que linformation soit organisée de la bonne façon. Une façon canonique dorganiser linformation consiste à définir une matrice de contrôle daccè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 lobjet o. Sur la plupart des systèmes, la matrice de contrôle daccès est trop grande pour être stockée en un seul endroit central.

19 Contrôle daccès Dans la pratique, deux approches sont utilisées pour représenter la matrice A : Liste des droits daccès («access control list», ACL) : La colonne dun 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 dun utilisateur. Cest lapproche du système dexploitation Unix. Capacités dutilisateur («User capabilities») : Pour chaque sujet, sa rangée est enregistrée. Il est facile de déterminer ce quun utilisateur peut faire, mais plus difficile de déterminer qui peut accéder à un certain objet. Cest lapproche du système dexploitation 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 dun utilisateur en : lutilisateur lui-même, le groupe de lutilisateur et les autres. Une variante de lidée de groupe dutilisateurs est appelée droits daccè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. Lorsquun utilisateur se connecte, alors un rôle lui est attribué. Ceci est un peu différent de lapproche par groupes dutilisateurs, car le même utilisateur peut jouer différents rôles à des moments différents.

21 Matrice de contrôle daccès dynamique Comment peut-on mettre à jour une matrice de contrôle daccès? Il y a deux approches : Mandatory Access Control : Les sujets ne peuvent pas changer la matrice de contrôle daccès. Discretionary Access Control : Les sujets peuvent modifier des parties de la matrice de contrôle daccès. Puisque le matrice de contrôle daccès peut changer en fonction du temps, il est naturel de demander quel type de circulation dinformation peut ainsi être produit : Ex. : Est-ce quun certain sujet peut éventuellement avoir accès à un certain objet en supposant que nous partions dune situation où ce nest pas le cas?

22 Analyse du contrôle daccè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 laccè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 dopérations. Si les conditions sont toutes vérifiées alors les opérations sont exécutées dans lordre.

23 Décider de laccès (I) Supposons maintenant que nous disposions dun ensemble de commandes C et dune matrice de contrôle daccè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 quune seule opération, alors il peut être décidé si A est sûre pour r. Si les commandes dans C peuvent contenir plus dune 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 laccès (II) En pratique, les commandes peuvent certainement contenir plus dune opération. De plus, il semble difficile de limiter le nombre de sujets davance. La conclusion est que les résultats précédents indiquent un problème important. Lindécidabilité ne fait quindiquer quil ny 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 lanalyse des systèmes de contrôle daccè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 lun des plus sûrs (sinon le plus sûr) pour la programmation sur lInternet. La sécurité Java offre deux caractéristiques importantes : La plateforme Java (par lutilisation 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 dapplications 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 na pas de construction de types qui ne soit pas sûre. Ex. : Il ny a pas de tableau sans vérification des indices. Ladministration 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 nest 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 Machin e La plateforme Fureteur Programme Java Serveur Applet Application Le langage Java, la machine virtuelle (JVM) et linterface de programmation dapplication («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») à laide dune table de symboles et dinformation auxiliaire. Le bytecode peut être aussi bien compilé quinterprété.

28 Larchitecture de sécurité pour JDK 1.0 Les applications ont accès a toutes les ressources vitales du système. Ce nest pas le cas pour les applets... Machin e Fureteur Serveur Applet Java 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 lapplet. Un environnement très restrictif pour le code non fiable obtenu dun réseau ouvert.

29 Vérificateur de bytecode Larchitecture de sécurité repose sur plusieurs mécanismes : Gestion de mémoire automatique, Le vérificateur de bytecode sassure 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 sassurer que les types soient utilisés de façon sûre à lexécution.

30 Vérification des types Le code est vérifié pour sassurer que : 1. Il ny ait pas de conversion de types illégale, 2. Il ny ait pas de pointeur falsifié (il ny a pas de pointeur en Java), 3. Il ny a pas de violation des restrictions daccès. Ex.: les champs privés ne doivent pas être consultés de lextérieur. 4. Les objets sont consultés de la façon prévue. Ex. : il faut sassurer quun 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 quelles 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 dun réseau local pourrait très bien fournir un service fiable même sil utilise des ressources du système hôte à lexté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 lapplet est traité comme une application.

32 Modèle de sécurité JDK 1.1 Ressources système (fichiers, connexions réseau...) Gestionnaire de Sécurité Carré de sable : accès restreint Accès non restreint Code externe Code local Code signé de confiance

33 Java 2 - Contrôle daccès fin Larchitecture 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 quils peuvent faire. Ceci même si certains applets sont plus dignes de confiance que dautres. Avec JDK 1.1, des applets signés permettent en partie de régler ce problème. Cependant, lutilisateur doit donner un chèque en blanc à la compagnie, ce qui nest peut-être pas toujours une bonne idée. Pour remédier à ce problème, Java 2 autorise un contrôle daccès flexible pour permettre aux applets de jouer à lexté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 daccès typés sont utilisables, en plus dun mécanisme de vérification des droits daccès qui soit extensible et flexible. La classe SecurityManager na 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 lhypothèse que les applications ont tous les privilèges. Le carré de sable ne sapplique quaux applets. Cependant, des applications installées localement ne devraient pas toujours avoir tous les droits daccè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 sil réside en mémoire. La différence entre code local et externe nest pas claire. En Java 2, le code local, externe ou signé est sujet au même contrôle de sécurité. Lutilisateur peut indiquer accès complet ou limité basé sur les propriétés du code et sur lidentité de celui qui lexécute. Ce choix consiste à établir une politique de sécurité appropriée.

36 Larchitecture de sécurité en Java 2 Java 2 utilise la politique de sécurité pour déterminer les droits daccès qui sont donnés au code exécuté. Ces permissions sont basées sur les caractéristiques du code, qui roule le code, doù il vient, sil est signé et si oui, par qui. Les demandes daccès aux ressources protégées invoquent une vérification qui compare la demande aux droits donnés. Si une politique nest pas explicitement donnée, alors la politique du carré de sable sapplique.

37 Sommaire de larchitecture (I) 1. Un fichier de classe est obtenu et accepté sil passe la vérification du bytecode préliminaire. 2. Le code source de la classe est déterminé. Sil est signé alors la signature est vérifiée. 3. Lensemble des droits daccès statiques (c.-à-d. indépendants de la politique), sil 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 daccès statiques. La classe est chargée et associée au domaine de protection. Si un domaine approprié a déjà été créé, alors ce ProtectionDomain est réutilisé à la place. 5. La classe peut être instanciée en objet et ses méthodes invoquées. La vérification des types continue. Voici comment une applet ou application est manipulé : un groupe contenant un code source avec ses permissions.

38 Sommaire de larchitecture (II) 6. Lorsquune 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 daccès examine le domaine de protection. La politique de sécurité est consultée et lensemble des droits daccès à être donnés est déterminé basé sur le code source et le principal qui indique qui roule le code. Lobjet Policy est aussi construit sil ne la pas déjà été. Cet objet maintient une représentation à lexécution de la politique de sécurité. 7. Lensemble des droits daccès est évalué pour décider si suffisamment ont été donnés pour satisfaire les requêtes daccès. Si oui, alors lexécution continue sinon une SecurityException est levée. 8. 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 lAppletViewer sur WriteFile signalera une SecurityException. Le droit décrire peut être donné à lapplet en utilisant le PolicyTool pour créer un politique mapolitique. Rouler lAppletViewer pour WriteFile avec mapolitique permettra dexé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 dattaques pour des versions antérieures de JDK, la JVM ou les fureteurs Java...

41 Attaques DATE APPLET MÉCHANTE Cible February 1996Jumping the FirewallNetscape2.0 : attaque un RP March 1996Slash and BurnNetscape2.01 : Applet -> trust March 1996Applets Running WildByteCodeVerifier,Netscape2.01 May 1996Casting Caution to the WindNetscape2.02,Explorer3.0b3 June 1996Tag-Team AppletsNetscape3.0b3 June 1996You're Not My TypeNetscape3.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 1997Steal This IP NumberNetscape3.x February 1997Cache CrammingExplorer3.x March 1997Virtual Voodoobug JVM April 1997The Magic Coat JDK1.1 -> bug signature de code May 1997Verifying the Verifier 27 erreurs dans vérificateurs de codes commerciaux July 1997The Vacuum Bug trou précédent lancé contre Netscape3.x :SSL August 1997Look Over ThereExplorer3.x et Netscape3.x July 1998Beat 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 lUdeM : 8-politique-securite-informatique-utilisation-ressources-informatiques-universite-de-montreal.pd f La page principale au sujet de la sécurité à lUdeM est : Voir la page Web du cours pour dautres liens à ce sujet....

43 Le contenu dune politique de TI Revenons sur ce quest une politique de sécurité pour un programme de sécurité en technologie de linformation. La politique est un élément critique dun 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é, lintégrité et la disponibilité des données et services. Elle donne aussi par écrit : La position de lorganisation sur les questions de sécurité, La description et laffectation de fonctions et responsabilités, Lattribution 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 daction, 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 linstitution.

45 Ses composantes (I) Définition : Une vision bien définie de la sécurité du point de vue de lorganisation. Donne le but de la politique. Ex. : Le préambule de la politique de sécurité de lUniversité de Montréal. Lexécution : Comment la politique va être exécutée et les réponses aux infractions. Laccès des utilisateurs aux ressources : Identifie les rôles et les responsabilités des utilisateurs qui utilisent les ressources. Incluant : Procédures pour obtenir laccès aux réseaux, et les niveaux de droits pour laccès aux ressources. Politiques interdisant lutilisateur à des fins personnelles, procédures pour lidentification des codes de conduite courriel applicables, spécifications pour les utilisations acceptables et inacceptables dInternet. Mots de passe, procédures pour la fermeture de comptes, procédures pour laccès à distance, guides pour lutilisation de machines personnelles. Restrictions pour linstallation d'applications et de matériel, un guide pour les applications. Procédures pour lannonce 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 linformation 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 larrêt de composantes matérielles. Dans bien des cas, la configuration par défaut des appareils nest pas suffisante. Il faut indiquer pour chaque appareil les configurations nécessaires pour satisfaire les besoins de lorganisation.

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 lutilisation du courriel est un plus. Est-ce quun filtrage des messages est nécessaire (éliminer les *.bat, *.exe, *.com,...)? Internet : Un politique dutilisation dInternet doit restreindre laccè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 davarie est nécessaire : La planification des sauvegardes, Lidentification du type de sauvegarde, Léquipement à utiliser, Lendroit où les sauvegardes seront rangées Tests de récupération, Les journaux («logx»),...

49 Ses composantes (V) Détection dintrusions : Quel genre dIDS 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 dintrusions 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 lorganisation. Par exemple : Installer et configurer des coupe-feu personnels sur les machines externes. Forcer linstallation dantivirus, de correctifs («patches») de sécurité récents. Le partage des fichiers reste inactivé. Les noms dutilisateur et les mots de passe doivent être chiffrés. Interdire la configuration des machines de lorganisation 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 lexistence de comptes périmés, mais toujours utilisés. Utilisation de techniques de piratage psychologique («social engineering») pour vérifier sil est possible dobtenir les mots de passe dun employé. Tester les sauvegardes. Simulation dune 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 demployé. 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 Quelques politiques Politiques diverses : Sauvegardes : DMZ : Mots de passe : Rappel : Voir le site Web pour dautres exemples...


Télécharger ppt "Politiques de sécurité 11 e cours (hiver 2014) Louis Salvail."

Présentations similaires


Annonces Google