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

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