Your SlideShare is downloading. ×
Sécurité des systèmes d'information
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Sécurité des systèmes d'information

5,212
views

Published on

Cours de Sécurité des Systèmes d'Information - Bases

Cours de Sécurité des Systèmes d'Information - Bases

Published in: Technology

0 Comments
17 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
5,212
On Slideshare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
0
Comments
0
Likes
17
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Sécurité des Systèmes d'Information Franck Franchin - Tous droit réservés 2013
  • 2. Objectifs Pédagogiques • Maîtriser les Notions associées à la Sécurité • Identifier et Cartographier les Risques d’un Systèmes d’Information (SI) • Appliquer les concepts de la Sécurité des SI • Evaluer la Sécurité des SI dans une entreprise • Intégrer la Sécurité dans le cycle de gestion de projet
  • 3. Concepts clés • Sécurité de l'Information (CISO) • Sécurité des Systèmes d'Information (CSO, RSSI) • Les systèmes d'information sont les premiers outils de traitement, de stockage et de conservation de l'Information, mais ce ne sont pas les seuls (local d’archives !)
  • 4. Sécurité d’un système ou d’un service • La sécurité d’un système ou d’un service est l'état d'une situation présentant le minimum de risques, à l'abri des dangers, des menaces. La mise en sécurité consiste à garantir la pérennité de cet état de sécurité par le recours à des moyens permettant soit de supprimer certains risques (mitigation) soit de les réduire à un niveau acceptable (risque résiduel). • Les anglo-saxons parlent de security (sécurité contre les actes malveillants) ou de safety (sécurité contre les risques accidentels).
  • 5. Sûreté de fonctionnement d’un système ou d’un service • La sûreté de fonctionnement d’un système ou d’un service est son aptitude d’une part à disposer de ses performances fonctionnelles et opérationnelles (fiabilité, maintenabilité, disponibilité) et d’autre part, à ne pas présenter de risques majeurs (humains, environnementaux, financiers). • Exemple : Sûreté d’une centre nucléaire • Les anglo-saxons parlent de dependability.
  • 6. Résilience d’un système ou d’un service • La résilience est la capacité d’un système ou d’un service à résister à une panne ou à une cyber-attaque et à continuer de fonctionner en garantissant un certain niveau de service (mode complet ou mode dégradé) puis à revenir à son état initial après l’incident. • Exemple : Résilience d’un système de commandement des secours/SAMU
  • 7. Protection des Actifs • Actifs matériels/tangibles • Destruction de matériels ou de supports • Vol de matériels • Actifs immatériels/intangibles • Marque • Goodwill / Survaleur • Propriété intellectuelle (IP) • Dommages directs ou indirects • Prévention / Détection • C.I.A. : Confidentiality Integrity Availability
  • 8. Confidentialité (Confidentiality) • Seules les personnes ou les programmes autorisés (politique de sécurité) ont accès aux informations qui leur sont destinées • Méthodes d’authentification et de contrôle d’accès • Notion de protection des données personnelles - Data privacy
  • 9. Intégrité (Integrity) • Les données ne doivent pas pouvoir être altérées et/ou modifiées de manière volontaire ou fortuite • L’origine ou la source des données doit aussi être clairement identifiée (personne ou organisation) afin d’éviter toute imposture • L’information doit aussi être transmise sans aucune corruption
  • 10. Disponibilité (Availability) • Les ressources et les services doivent être garantis en performance (temps de réponse) et en fonctionnement (% de disponibilité) • La disponibilité d’un système informatique peut être affectée : • par des soucis techniques (dysfonctionnement d’un ordinateur ou d’un équipement de télécommunication) • Par des phénomènes naturels (inondation) • Par des causes humaines (accidentelles ou délibérées) • Exemple : Disponibilité de 99.99 % : 2h d’interruption de service par an
  • 11. Fiabilité (Reliability) • Capacité d’un système à fonctionner correctement sous certaines conditions connues pendant une période de temps définie • Peut-être définie comme la probabilité d’une défaillance (panne) ou par leurs fréquences probabiliste. • MTBF : Mean Time Between Failure
  • 12. Maintenabilité (Maintenability) • Capacité d’un système informatique à revenir à une état normal de fonctionnement après une défaillance (panne) lorsque les opérations de maintenance correctives ont été appliquées selon des procédures prédéfinies • MTTR (Mean Time To Repair) • Compromis et optimisation entre la fiabilité et la maintenabilité
  • 13. Traçabilité (Tracking) • Garantie que les accès aux programmes et aux données sont tracés dans un journal d’événements conservé, horodaté et exploitable. • Exemple : Historique de navigation effacé mais Journal des événements système intact
  • 14. Auditabilité (Auditability) • Capacité d’un système à pouvoir être audité pour s’assurer de la validité et de la fiabilité de ses informations et pour évaluer l’application des diverses procédures d’exploitation et processus de gestion et de contrôle • Exemple : horodatage et imputabilité des actions effectuées par un salarié sur son poste de travail (carte à puce ou token + PKI + chiffrement du disque)
  • 15. Contrôle d’Accès • Processus de délivrance de droits d’accès à des personnes, à des programmes ou à des ordinateurs dûment autorisés à accéder, en lecture et/ou en écriture, à des ressources informatiques. • Par extension sémantique, mécanisme destiné à limiter l’utilisation de ressources spécifiques à des utilisateurs autorisés • Pare-feu (firewall) : règles par protocole, origine, destination • Constitue la première ligne d’une Défense en profondeur (defense in depth) • Besoin d’en connaître (need to know) • Horodatage, Non-répudation, Imputabilité
  • 16. Gouvernance des Systèmes d'Informations • La Gouvernance est un processus qui permet de contrôler stratégiquement des fonctions grâce à des politiques, des objectifs, des délégations de responsabilité, des audits et des métriques. • La Gouvernance permet aux organes de direction de s'assurer que les processus IT répondent bien aux besoins de l'entreprise. • La Gouvernance est définie et suivie par un Comité de pilotage par rapport à des orientations définies par un Comité Stratégique. • Le Comité de pilotage est chargé entre autre de l'application des politiques, des best practices, des prioritarisations, des standards à choisir et à implémenter, de la gestion des contractants et de la direction de projets et de programmes
  • 17. Gouvernance de la Sécurité de l'Information • Ce processus a pour rôle d'identifier les acteurs et les responsabilités, d'identifier et de traiter les risques sur les actifs tangibles et intangibles clés et de mesurer l'efficacité des processus de sécurité • Il s'articule principalement autour de 5 acteurs : le Comité Exécutif, le Comité des Risques, le Comité de Pilotage de la Sécurité de l'Information, le CISO (Chief Information Security Officer) et les employés de l'entreprise
  • 18. Politiques, Processus, Procédures et Standards • Ces 4 concepts définissent comment est pilotée et implémentée la sécurité de l'information et des systèmes d'information • Les procédures décrivent étape par étape comment certaines tâches d'un processus doivent être exécutées et quels sont les impacts ou les dépendances sur d'autres procédures • Parmi les standards, on va retrouver des technologies, des protocoles, des méthodologies et des architectures
  • 19. Politiques de sécurité • Les politiques de sécurité définissent ce qui peut ou ne peut pas être fait au niveau systèmes d'information et traitement de l'information • Elles définissent comment l'entreprise ou l'organisation cible va protéger ses actifs critiques • Ce sont des documents fondateurs destinés à durer dans l'entreprise • Elles couvrent en général les domaines suivants : • Les rôles et les responsabilités • La gestion des risques • Les processus de sécurité • La gestion des données relatives à la vie privée (salariés et clients) - privacy • Les politiques de sécurité et le pilotage de la sécurité doivent être indépendants de leurs cousins IT
  • 20. Vie privée et Protection des données • Concerne le stockage et les traitements associés des données des salariés, des clients mais aussi d'autres parties prenantes (contractants, business partners, organisations syndicales, membres externes des conseils d'administrations) • La politique de 'privacy' décrit comment sont collectées ou obtenues les données privées, comment elles sont protégées et quels types de traitements sont opérés • Elle décrit aussi comment sont éventuellement transmises ces informations à des tiers, comment il est possible de connaître quelles données personnelles sont conservées et comment demander leur suppression ou leur modification
  • 21. Gestion des Risques • Les activités, les pratiques et les données d'une entreprise sont sujettes à des risques. • La gestion des risques ou risk management est l'activité qui consiste à rechercher, identifier et gérer ces risques. • C'est un processus cyclique, continu, qui nécessite le support de l'ensemble des métiers de l'entreprise • Une fois les risques identifiés, ce processus se pilote à travers quatre actions possibles qui peuvent être associées entre elle : • Accepter le risque tel quel, • Mitiger le risque, c'est à dire prendre les mesures nécessaires pour réduire son exposition • Transférer le risque à une partie tierce, habituellement un assureur • Eviter le risque, c'est à dire en général supprimer la source du risque, habituellement l'activité ou les données associés
  • 22. Le processus de la gestion des risques • La première étape consiste à définir des objectifs précis : par exemple réduire le nombre d'accidents industriels, le coût des primes d'assurance ou le nombre de vols • La seconde étape, souvent délicate, consiste à définir le périmètre (BUs) • Il est crucial que le programme de gestion des risques soit porté par un sponsor de niveau exécutif formellement engagé dans la démarche, afin de lui garantir sa crédibilité • Les rôles et les responsabilités de chacun doivent être clairement définis • Des ressources doivent être allouées à tous les intervenants du processus, en coûts directs ou indirects • L'identification des risques, leurs analyses, leurs traitements et toute autre activité d'audit ou de métrique, doivent suivre un processus de gestion documentaire
  • 23. Le cycle de vie de la gestion des risques • C'est un processus vertueux ! • 3 phases : • Identification des actifs tangibles et intangibles • Analyse de risques (à partir des vulnérabilités connues) • Traitement des risques (mitigation, transfert, suppression)
  • 24. Identification des actifs • Actifs tangibles, intangibles, physiques, logiques ou virtuels, souvent regroupés par type ou par lieu • Quelques exemples : • Bâtiments ou Terrains • Equipements • Informatique • Approvisionnements et Matières premières • Journaux d'activité (contrats formés, video-surveillance, visiteurs, comptabilité) • Informations critiques pour les opérations de l'entreprise • Propriété intellectuelle • Collaborateurs • Réputation • Marques
  • 25. Analyse de Risques • Ce processus consiste à analyser et pondérer chaque risque identifié selon les menaces, les vulnérabilités et les impacts associés Risque = Impact * Probabilité • Cette équation implique que le risque est quantifié, ce qui n'est pas toujours facile pour des risques plutôt qualitatifs • Pour chaque actif, il convient d'étudier les vulnérabilités intrinsèques ou extrinsèques en regard des menaces connues (humaines, naturelles ou dues au hasard)
  • 26. Recherche des menaces • Menaces naturelles • Tornade, ouragan, inondation, neige, coulée de boue • Tremblement de terre, avalanche, tsunami, éruption volcanique • Maladies, épidémie • Incendie • Menaces humaines • Grèves • Sabotage • Incendie • Emeute, pillage, terrorisme, guerre • Criminalité (chantage, extorsion, vol, vandalisme, intrusion) • Malware • Défaillances matérielles (chauffage, ventilation, climatisation, énergie, eau, telecom) • Défaillances logicielles • Accidents (train, avion, bateau, autoroute) • Substances chimiques dangereuses, radio-activité • Erreur humaine !
  • 27. Recherche des vulnérabilités • Une vulnérabilité est une faiblesse ou une absence de protection qui peut renforcer les menaces ou exposer les actifs • Une vulnérabilité peut-être intrinsèque ou extrinsèque • Quelques exemples de vulnérabilités : • des détecteurs d'incendie non câblés • pas de politique de patches de sécurité • anti-virus facilement désactivable • clé Wifi WEP • mot de passe trop simple ou trop court • Il convient de classer les vulnérabilités par leur sévérité ou leur criticité (Low, Medium, High, Critical) • Attention : Le classement d'une vulnérabilité ne doit pas dépendre de la probabilité qu'une menace exploite cette vulnérabilité mais uniquement des dommages directs ou indirects résultants.
  • 28. Analyse qualitative des risques • Les menaces, les vulnérabilités et les impacts sont classés selon des échelles de valeur et chacun est analysé et évalué en profondeur • L'analyse qualitative s'occupe principalement des risques les plus élevés d'une organisation ou d'une entreprise • Elle s'applique aussi assez bien aux actifs intangibles (impact sur la marque, sur la réputation) et sur les risques inacceptables
  • 29. Analyse quantitative des risques • L'avantage de la quantification des risques c'est qu'il est permis de mettre en regard la valeur des actifs, la plupart du temps en terme financier, aisément compréhensible par l'ensemble de l'entreprise • Toute analyse de risques est une mesure d'événements qui peuvent se produire et non qui se sont produits réellement.On reste donc dans le domaine d'une évaluation et d'une probabilité. • Plusieurs concepts : • Valeur d'Actif (Asset Value - AV) - en général la valeur de remplacement de l'actif • Facteur d'Exposition (Exposure Factor - EF) - la perte financière qui résulterait de la réalisation de la menace par rapport à la valeur de l'actif (en %). La plupart des menaces n'aboutissent pas à la perte de l'actif mais à sa dégradation • Perte unique (Single Loss Expectancy - SLE) - AV * EF, c'est à dire la perte financière d'une menace réalisée une fois • Taux annuel d'occurrences (Annualized Rate of Occurence - ARO) - L'estimation du nombre d'occurrences de la menace par an • Perte annualisée (Annualized Loss Expectancy - ALE) - SLE * ARO
  • 30. Comment traiter les risques ? • Quatre décisions possibles : • Mitiger le risque - Implémenter une ou plusieurs solutions qui réduisent le risque (par ex: anti-virus, IDS/IPS) • Accepter le risque - Le Management décide d'accepter le risque ou de l'auto-assurer • Transférer le risque - Principalement par contrat avec un tiers assureur ou un tiers responsable (sous-traitant ou fournisseur !) • Supprimer le risque - Suppression ou destruction de l'actif ou de la menace (!) • Risque résiduel - Que le risque ait été réduit ou transféré, il reste toujours un risque résiduel, qui doit être documenté et soumis à connaissance (voire approbation) du management
  • 31. Management de la Sécurité de l'Information • Ensemble des politiques, des processus et des procédures qui garantissent que la politique de sécurité d'une organisation est garantie • Consiste entre autre à : • Ecriture des politiques de sécurité • Application des politiques de sécurité • Formation et Sensibilisation (Awareness) • Gestion des identités • Gestion des droits d'accès physiques et logiques • Gestion des incidents de sécurité (SIM - Security Incident Management) • Gestion des vulnérabilités • Politique de chiffrement
  • 32. Politiques de sécurité • Engagement et Support du Top Management • Rôles et Responsabilités • Valorisation des actifs liés à l'information et nécessité de les protéger (tangibles ou intangibles) • Protection des actifs liés à l'information (confidentialité, intégrité, disponibilité) • Comportement et Ethique (ce qui est exigé, permis et interdit) • Gestion des risques (mesure et traitement) • Lois et Régulations (droit des Télécoms, de la Concurrence...) • Conséquences des violations de la politique de sécurité
  • 33. Sensibilisation à la Sécurité Une formation vaut mieux que deux pare-feux tu auras.. • Aider les collaborateurs d'une entreprise à comprendre : • La valeur des actifs tangibles et intangibles, en particulier de l'information, qu'ils manipulent dans l'exercice quotidien de leurs missions • Les risques auxquels ils sont exposés ou auxquels ils exposent d'autres • Les mesures appliquées par l'entreprise et celles qu'on leur demande d'appliquer pour réduire ces risques • Les comportements déconseillés ou interdits
  • 34. Continuité Opérationnelle • Plan de Continuité - BCP (Business Continuity Planning) • Le BCP permet à une entreprise de détailler comment elle peut poursuivre son activité en cas de sinistre, éventuellement en mode dégradé • Cadre réglementaire : Bâle 2, Sarbanes Oxley, etc. • Plan de reprise d’activité - DRP (Disaster Recovery Planning) • Le RDP permet d'assurer, en cas de crise majeure ou importante, la reconstruction et la remise en route des applications supportant l'activité d'une entreprise. • Les besoins sont exprimés par une durée maximale d'interruption admissible (Recovery Time Objective, RTO) et une perte de données maximale admissible (Recovery Point Objective, RPO), avec ou sans mode dégradé.
  • 35. Gestion des Incidents • Un incident de sécurité est un évènement qui compromet directement ou indirectement la confidentialité, l'intégrité et/ou la disponibilité d'une information ou d'un système d'information : • Divulgation volontaire ou involontaire • Vol d'information ou d'élément(s) du système d'information • Atteinte volontaire ou involontaire à l'information (corruption de l'information) • Malware (virus, troyan, vers, rootkits, ...)
  • 36. Droits d'accès et Gestion des Identités • Processus, procédures et règles (business rules) qui gèrent les droits d'accès aux informations et aux systèmes d'information : • Demandes d'accès, avec processus d'approbation (hiérarchie mais aussi propriétaire de l'information) • Revues périodiques des droits d'accès • Revues périodiques des règles de ségrégation (secret, confidentiel, réservé, public) • Fin de droits (départ, mutation, etc...)
  • 37. Protection de l'information et Vie Privée • Concerne les données relatives aux collaborateurs, aux tiers parties prenantes et aux clients • Types d'informations privées : • Date et Lieu de naissance • Lieu de résidence • Numéros de téléphone fixes et mobiles • Photos personnelles • Numéro de Sécurité Sociale • Numéro de pièces d'identité (CI, Passeport, Permis de conduire) • Comptes bancaires • Cartes de crédit
  • 38. Cybercriminalité • Les informations et/ou les systèmes d'information sont impliqués dans des actes délictueux : • En tant que cibles (vol, vandalisme, intrusion) • En tant qu'instruments (intrusion, vol de données, sabotage, pédopornographie, diffamation ou dénigrement, espionnage, interception ou écoutes, spam)
  • 39. Cybercrimes • Les crimes commis dans l'espace cybernétique sont analogues à ceux commis dans l'espace physique. • Plusieurs catégories : • Politiques • Terrorisme • Militaire et Services de renseignements • Financiers (vol ou détournement de fonds, cartes de crédit, fraude...) • Business (espionnage industriel, extorsion, chantage, DoS...) • Rancune ou Vengeance • Fun ou Passe-Temps (!)
  • 40. Les auteurs des cybercrimes • Hackers • Espions et Agences de renseignement • Terroristes • Cyber-Activistes • Crime organisé et Mafia • Script Kiddies • Employés (!) • Anciens employés (!!) • Concurrents
  • 41. Actes cybercriminels sur les organisations • Financiers (numéros de cartes de crédit ou de comptes bancaires, fraude) • Chantage et extorsion (DDoS...) • Divulgation d'informations confidentielles • Sabotage, Defacement • Atteint à l'image de marque ou à la Réputation • Risques juridiques ou réglementaires
  • 42. Prévention & Sécurité Il vaut mieux prévenir que guérir • Veille pro-active sur les vulnérabilités et les menaces (CERT, Secunia, Bugtraq, ...) • Patch Management (Microsoft Tuesday, Adobe Everyday !) • Défense en profondeur et Durcissement des systèmes afin de réduire ou minimiser les surfaces d'attaque • Détection d'intrusion (IDS - Intrusion Detection System) et Prévention d'intrusion (IPS - Intrusion Prevention System)
  • 43. Forensiques • Il est primordial d'analyser tout incident de sécurité, même si (et surtout si...) aucun dommage n'a été décelé : Analyse Post-Mortem • Un certain formalisme doit être observé en cas de poursuites judiciaires (pénal ou Prud'Hommes) • Une enquête forensique doit permettre d'identifier les preuves et les outils utilisés pour les collecter, de préserver ces preuves, de les analyser, de reconstruire le scénario de l'attaque et de présenter ces résultats sous une forme compréhensible à la fois par les experts et les juristes
  • 44. Contrôle d'Accès • Le Contrôle d'Accès aux informations et aux systèmes d'information s'articule principalement autour de 4 concepts : • ACL - Access Control Lists (systèmes d'exploitation, NAS, routeurs, pare-feus) • Identification - "Bonjour, c'est moi !", identité fournie mais non prouvée (par exemple : cookie) • Authentification - "Bonjour, voici ma carte d'identité", identité fournie et prouvée (mot de passe, token, biométrie, carte à puce ou certificat numérique). L'authentification peut nécessiter 2 preuves (two-factor authentication). Elle peut aussi être centralisée (LDAP, RADIUS, Microsoft AD, SSO - Single Sign On) • Autorisation - "Bonjour, voici mon permis de séjour", identité fournie, prouvée et accès autorisé (vérification dans l'ACL de la ressource à laquelle l'accès est demandé)
  • 45. Cryptographie Les technologies de chiffrement sont à la base de la plupart des mécanismes de sécurité moderne : hash, certificat numérique, signature numérique, nonrépudiation, stéganographie, watermarking, authentification La Cryptographie sera à la base de l'Internet de demain
  • 46. Cryptographie - Généralités • Chiffrement (Encryption), Déchiffrement (Decrypting), Algorithme, Cryptographie, Cryptanalyse, Chiffrement de blocs (Block Ciphering), Chiffrement de flux (Stream Ciphering), Chiffrement Symétrique, Chiffrement Asymétrique • Message : message texte, binaire, hexa, fichier ou bloc ou flux (stream) de données • Clé (Key) de chiffrement, Longueur de la clé, Echange de clés • Message original (plaintext), Message chiffré (ciphertext) • Hachage (hash), fonction cryptographique appliquée à un bloc de données, le message, qui retourne une chaine de caractères de longueur fixe, utilisée pour vérifier l'intégrité du message (digest) • Signature numérique (chiffrement du hachage d'un message avec la clé privée de celui qui l'a écrit) : preuve d'authenticité et d'intégrité
  • 47. Quelques Applications • SSL/TLS - Secure Sockets Layer / Transport Layer Encryption - Protocoles standards de facto de chiffrement associés aux requêtes HTTPS (http secure) introduits par Netscape. Authentification principalement du serveur et accessoirement du client et chiffrement de la session (AES, RC4, IDEA, DES, 3DES pour des longueurs de clés de 40 à 384 bits) • S-HTTP - Secure Hypertext Transfer Protocol - Ne pas confondre avec https • S/MIME - Secure Multipurpose Internet Mail Extensions - Protocole de sécurité de messagerie qui permet l'authentification et le chiffrement des messages et des pièces jointes • SSH - Secure Shell - Protocole qui permet de créer un canal de communication sécurisé entre 2 systèmes (remplace l'horrible telnet !) et permet aussi de faire du tunneling de protocoles tels que X-Windows et FTP. • SET - Secure Electronic Transaction - Ancien protocole qui permettait de sécuriser les transactions financières sur Internet
  • 48. Chiffrement Symétrique Mode de fonctionnement : Echange de la clé de chiffrement (canal de communication parallèle) “Shared Key” ou “Private Key” Pros/Cons : Très rapide Implémentation hardware ou software Gestion complexe des clés (nombre et échange) Exemples: Algo de César Machine Enigma DES/3DES/AES Blowfish (Bruce Schneier)
  • 49. Chiffrement Asymétrique Mode de fonctionnement : Utilisation d’une paire de clés, liées mathématiquement Une clé déchiffre (clé privée, secrète), l’autre clé chiffre (clé publique) Il est normalement impossible de retrouver la clé privée à partir de la clé publique (algorithme “one-way”) Pros/Cons : Gestion des clés facilitée Lent : 100 à 1000 fois plus lent qu’un chiffrement symétrique Exemples : 1976 : Diffie / Hellman RSA Elliptic Curve (ECC) Hash (MD5, SHA)
  • 50. PKI PKI (Public Key Infrastructure) : ensemble de matériels, de logiciels, de protocoles de communication et de processus de gestion qui permet d’utiliser, de gérer et de contrôler de la cryptographie à clé publique Chiffrement mixte - La cryptographie symétrique sert à chiffrer les messages puisque cette fonction est très rapide et la cryptographie asymétrique sert à échanger les clés entre deux utilisateurs puisqu'il faut leur donner des clés identiques et de manière sûre pour qu'ils chiffrent et déchiffrent leurs messages. Comme l'échange de clés ne se fait qu'une seule fois, le système n'en est que très peu ralenti. Un autorité de certification, CA ( Certification Authority), signe le certificat numérique et atteste de l’existence et de l’identité réelle du possesseur du-dit certificat (IDCard) Le CA peut révoquer des certificats
  • 51. Méthodologies d'Analyse de Risques • MEHARI - MEthode Harmonisée d'Analyse de RIsques • A l'initiative du CLUSIF en 1996, nouvelle version en 2010 • Open Source, téléchargée plus de 34000 fois par plus de 170 pays • Conforme aux exigences de l’ISO-27001 et 27005 • EBIOS - Expression des Besoins et Identification des Objectifs de Sécurité) • A l'initiative du DCSSI/ANSSI en 1995, nouvelle version en 2010 • Conforme aux normes internationales ISO 31000, ISO 27005 et ISO 27001
  • 52. MEHARI • Mehari fournit un cadre méthodologique, des outils et des bases de connaissance pour : • analyser les enjeux majeurs, • étudier les vulnérabilités, • réduire la gravité des risques, • piloter la sécurité de l'information.
  • 53. MEHARI • MEHARI propose une séparation en 8 types de cellules : • l'entité ; • le site ; • les locaux ; • les applicatifs ; • les services offerts par les systèmes et l'infrastructure ; • le développement ; • la production informatique ; • les réseaux et les télécoms.
  • 54. Analyse des Enjeux sous MEHARI • Dans une logique « métiers » de l’entreprise, centrée sur les impacts business, elle consiste à : • L'identification des dysfonctionnements potentiels pouvant être causés ou favorisés par un défaut de sécurité, • L'évaluation de la gravité de ces dysfonctionnements • Elle permet de définir les priorités, d’être sélectifs et d’optimiser les ressources
  • 55. Analyse des Vulnérabilités sous MEHARI • L'analyse des vulnérabilités revient à identifier les faiblesses et les défauts des mesures de sécurité, sous la forme d'une évaluation quantitative, décrits et documentés dans une base de connaissance développée et maintenue par le CLUSIF : • Efficacité par conception (hauteur de la digue) • Robustesse (qualité du ciment de la digue) • Mise sous contrôle (fermeture des vannes de la digue) • Comparaison par rapport à l’état de l’art ou aux normes en usage
  • 56. Risques & Scénarios sous MEHARI • Les risques sont classés selon le type de leur cible. • Chaque scénario doit avoir : • une seule cause : erreur, malveillance, accident ; • une seule conséquence : atteinte à la disponibilité, intégrité, confidentialité. • MEHARI apporte des bases de connaissance, des métriques de risque, et une démarche structurée d’évaluation
  • 57. Pilotage de la Sécurité sous MEHARI • Piloter la sécurité signifie : • Définir des objectifs annuels ou les étapes de plans d’action • Définir et Relever des indicateurs qui permettent de comparer les résultats obtenus aux objectifs en termes qualitatifs, quantitatifs et de délais • Etre capable d’effectuer du benchmarking
  • 58. Normes 27001, 27002 et 27005 • ISO/CEI 27001 publiée en Octobre 2005 pour remplacer la BS7799-2 • Modèle PDCA : Plan, Do, Check, Act/Adjust (Roue de Deming ou de Shewhart) • L’annexe ISO/CEI 27002, publiée en Juillet 2007, est un guide de bonnes pratiques et précise les domaines pour l’analyse de risques et les contrôles à effectuer, dont 133 mesures de sécurité (best-practices), classées en 11 section. • Cela peut constituer un référentiel d’audit et de contrôle mais il y a un travail important de personnalisation aux activités de l’entreprise et/ou du périmètre • ISO/CEI 27003, publiée en Janvier 2010, est un guide d’implémentation du SMSI en 5 étapes • ISO/CEI 27004 concerne la gestion des indicateurs, métriques et mesures de l’efficacité du SMSI • ISO/CEI 27005 concerne l’analyse des risques, avec 6 annexes qui présentent des listes de menaces et vulnérabilités • ISO/CEI 27006 est une reprise enrichie de l’ISO 17021 destinée à la certification et aux cabinets d’audit • En cours de rédaction : • ISO/CEI 27007 - Audit des SMSI • ISO/CEI 27008 - Audit des mesures de sécurité de la 27002 (analyse des besoins en contrôle)
  • 59. Norme 27001 : Exigences et SMSI • La norme ISO/CEI 27001 décrit les exigences pour la mise en place d’un Système de Management de la Sécurité de l’Information (SMSI)(Information Security Management System - ISMS). • La 27001 a une approche par processus, ce qui permet de choisir et d’organiser les meilleurs pratiques et de les faire évoluer dans le temps. • Le SMSI est un dispositif global de gouvernance de la sécurité de l’information. Il englobe l’ensemble des documents définissant les règles et les processus de sécurité, les organisations associées ainsi que les infrastructures techniques de sécurité. • Le SMSI permet de choisir les mesures de sécurité nécessaires pour assurer la protection des actifs tangibles et intangibles d’une entreprise sur un périmètre défini. • Ces mesures de sécurité doivent être adéquates et proportionnelles au périmètre sélectionné.
  • 60. Norme 27001 : Gouvernance • La démarche est basée sur des processus de sécurité. Elle s’articule principalement sur une analyse de risques et sur un plan de traitement de ces risques dont l’application est strictement contrôlée à travers un pilotage : • Une gestion des incidents • La mise sous contrôle des éléments du SMSI • La gestion de configuration de la documentation de sécurité • La traçabilité et l’imputabilité des contrôles des mesures de sécurité. • Elle permet de mieux optimiser les budgets sécurité et de mieux associer les filières métiers et les opérationnels • Cette gouvernance a pour principal but l’amélioration continue de la sécurité
  • 61. Norme 27001 : Phase Plan • Fixation des objectifs du SMSI : • Politique et périmètre du SMSI • Appréciation/Analyse des risques
 (Identification des actifs, des propriétaires d’actifs, des vulnérabilités, des menaces, des impacts ; Evaluation de la vraisemblance ; Estimation des niveaux de risque) • Traitement des risques et risques résiduels
 (Accepter, Eviter, Transférer, Réduire) • Sélection des mesures de sécurité (SoA - Statement of Applicability)
  • 62. Norme 27001 - Phase Do • Mise en oeuvre des mesures de sécurité : • Plan de traitement • Choix des indicateurs • Formation et Sensibilisation des collaborateurs • Maintenance du SMSI
  • 63. Norme 27001 - Phase Check • Moyens de contrôle pour s’assurer de l’efficacité du SMSI et sa conformité au cahier des charges de la 27001 • Pour cela : • Contrôles internes (vérification que les procédures sont bien appliquées) • Audits internes (écarts entre ce qui est écrit et ce qui est fait) • Revues périodiques de management pour analyser les événements de sécurité
  • 64. Norme 27001 - Phase Act • Trois types d’actions possibles : • Actions correctives • Actions préventives • Actions d’amélioration
  • 65. RGS : Référentiel Général de Sécurité • Ordonnance 2005-1516 du 8 décembre 2005 rédigée par l’Agence Nationale pour la Sécurité des Systèmes d’Information (ANSSI, ex-DCSSI) qui encadre l’accès à des services électroniques de l’administration française (entre usagers et autorités administratives (AA) et entre autorités administratives) via le respect de règles de sécurité (RGS) et de règles d’interopérabilité (RGI). Décret d’application 2010-112 du 2 Février 2010 • Travail conjoint entre l’ANSSI et la Direction générale la modernisation de l’Etat (DGME) • Démarche globale : aspects techniques et non-techniques, risques de toute origine, responsabilisation des acteurs, vision stratégique et intégration de la SSI sur la totalité du cycle de vie des projets • Gérer les risques grâce à l’ISO 27005 et EBIOS • Exprimer les besoins de sécurité (Fiche d’Expression Rationnelle des Objectifs de Sécurité - FEROS) • Elaborer une Politique PSSI • Utiliser des outils et des prestataires de service de confiance (PSCo) et homologuer la sécurité des services • Mettre en oeuvre un SMSI conforme à l’ISO 27001 dans un but de processus vertueux d’amélioration continue
  • 66. RGS : Aspects techniques • Utilisation de la cryptographie (authentification, confidentialité, certificats, signature électronique, horodatage, accusé de réception signé) • Qualification des produits de sécurité (3 niveaux basés sur EAL3 et EAL 4) • PKI
  • 67. Comment intégrer la sécurité dans les projets ? • La plupart des logiciels et des systèmes d’information sont conçus en priorité pour offrir certaines fonctionnalités : la sécurité a rarement été prise en compte lors de la conception, du développement et du déploiement • Il convient de mener des analyses de risques dès la phase de conception et non d’appliquer des « patchs » de sécurité une fois les spécs fonctionnelles et techniques écrites et validées • Nécessité de comprendre les besoins de sécurité d’une application par rapport à son éco-système, à la politique de sécurité de l’entreprise et à la sensibilité des données qu’elle traite
  • 68. Où placer la sécurité ? • La mauvaise méthode dite périmétrique : faire confiance à des pare-feus, à des IDS/IPS, à des systèmes de filtrage de contenus, à des scanners de vulnérabilités, à des anti-virus, etc… pour détecter et éviter que les applications contiennent des vulnérabilités • Le succès de cette « méthode » est principalement dû au fait que la plupart des développeurs n’ont pas de compétences en sécurité et que les outils ou composants logiciels tierces qu’ils emploient présentent eux aussi des trous de sécurité (bogues, vulnérabilités, faiblesses) • La course à mettre sur le marché de nouveaux logiciels et l’accélération technologie n’ont fait qu’empirer la situation.
  • 69. Mais où donc placer la sécurité ? • La bonne méthode dite de Security by Design : adresser les problématiques de sécurité à leur source, c’est à dire au niveau de la conception et du développement du logiciel • Il faut penser proactif et non réactif • Environnement versus Application : les différents contrôles nécessaires à la sécurité peuvent être implémentés au niveau du système d'exploitation, de la couche applicative et du système de gestion de bases de données ; en réalité des trois
  • 70. Sécurité applicative • Carnegie Mellon University estime qu'il y a 5 à 15 bogues toutes les 1000 lignes de code • Type et taille des données : le fameux buffer overflow • La valeur par défaut devrait toujours être : Non ! • Limiter au maximum l'utilisation d'un niveau privilégié. La plupart du code, voire sa totalité, devrait pouvoir s'exécuter en mode utilisateur • Prévoir et intégrer dès la conception la résilience du programme : si le programme crashe, il doit effectuer un certain nombre de tests d'intégrité avant d'offrir à nouveau ses fonctionnalités
  • 71. Sécurité des données • Garantir la CIA de la structure de la base de données et des données • Avant, seuls les employés d'une entreprise accédaient aux données des clients. Aujourd'hui, ce sont les clients qui accèdent eux-mêmes à leurs propres données via un navigateur • Les vulnérabilités se nichent souvent au niveau des middlewares qui permettent d'accéder aux informations (ODBC, OLE DB/ADO, JDBC) • Accès concurrent = soucis d'intégrité (sémantique, référentielle et entité unitaire) ! Rollback, Commit, Savepoints and Checkpoints ! • OLTP (Online Transaction Processing) - ACID Test : • Atomicity : décomposition des transactions et vérification que toutes commités sinon rollback • Consistency : une transaction doit suivre les règles d'intégrité de la base de données • Isolation : le résultat d'une transaction n'influe pas sur les autres transactions • Durability : Une fois que la transaction est vérifiée, elle est commitée partout et son rollback est impossible
  • 72. Analyse de risques pour un dév logiciel • Buffer overflows possibles ? Comment les éviter et les tester ? • Est ce qu'on teste bien le format et la validité de toutes les données saisies par l'utilisateur ? • Est-ce que l'application est sensible et peut être la cible d'un agent menaçant ? • Quelle activité de l'entreprise dépend de cette application et quelle perte peut être occasionnée si l'application est HS ? • Est-il possible à un tiers d'écouter et d'analyser les échanges avec cette application ? • Quelle tolérance aux pannes doit être intégrée ? • Est-il nécessaire de chiffrer les données ou le code ? • Faut-il concevoir un plan de secours en cas de crash ? • Est-ce que l'application sera hébergée et/ou exploitée par un tiers ? • Est-ce que l'application sera visible ou accessible depuis l'Internet ? • Est-ce que l'application sera interconnectée à un système potentiellement vulnérable ou hors contrôle ? • Est-ce que l'application est sensible ou vulnérable au DoS ? • Est-ce que des mécanismes de détection d'intrusion ou d'offuscation sont nécessaires ? • Est-il possible de frauder grâce à cette application ?
  • 73. Séparation des pouvoirs • Développement, Test et Mise en production doivent être effectué par des équipes différentes • Processus récurrent : • Identification d'une vulnérabilité (pentest ?) • Création du scénario de test associé • Test en environnement proche de l'environnement de production • Revue du code impacté • Solution,Modification du code et test • Versioning du code • Tests unitaires, tests d'intégration, tests de validation fonctionnelle et tests de régression • Post-mortem....
  • 74. Common Criteria : Méthode d'évaluation de la sécurité • L'Orange Book, le Red Book, le TCSEC et l'ITSEC se sont révélés trop lourds, trop complexes et pas assez souples ; l'industrie s'est tournée vers les Critères Communs (Common Criteria : CC), projet commencé en 993 sous l'égide de l'ISO • Les CC évaluent un produit par rapport à un profil de protection qui correspond à un besoin réel (cible de sécurité) • Selon le modèle CC, le résultat de l'évaluation donne un niveau EAL (Evaluation Assurance Level) en 7 classes : EAL1 à EAL7

×