Successfully reported this slideshow.

Modéliser les menaces d'une application web

11

Share

Loading in …3
×
1 of 130
1 of 130

Modéliser les menaces d'une application web

11

Share

Description

Etude de cas - Modélisation des menaces d'une application web

Forum PHP - 2012
Cité Universitaire, Paris

Transcript

  1. 1. Modéliser les menaces d'une application web étude de cas Antonio Fontes antonio.fontes@owasp.org 5 juin 2012 Décharge: aucun chat n'a été blessé ou importuné durant la préparation de ce document.
  2. 2. Quelques questions… 2
  3. 3. Quel interpréteur pourrait être la cible d'une tentative d'injection? (une à plusieurs réponses possibles) A. Interpréteur de requête XPath B. Interpréteur de requête SQL C. Interpréteur de requête LDAP D. Interpréteur de nom de fichier E. Interpréteur de session SMTP F. Tous ceux mentionnés G. Une injé…quoi?? 3
  4. 4. La meilleure méthode pour empêcher une injection SQL? (une à plusieurs réponses possibles) A. Validation de données B. Canonisation puis validation de données C. Encodage de données D. Requête SQL paramétrée E. Canonisation de données F. Validation puis canonisation G. Il faut tout faire!!! 4
  5. 5. Qu'est-ce qui est plus grave? (une réponse autorisée) A. Une injection SQL. (A1) B. Une référence directe non sécurisée. (A4) C. Une clé de chiffrement à entropie basse (A9) 5
  6. 6. Qu'est-ce qui est plus grave? (une réponse autorisée) A. Une injection SQL…sur la page d'accueil du site web de la boucherie du village. B. Une référence directe non sécurisée…sur le lien de consultation en ligne des factures d'un fournisseur national d'énergie. C. Une clé de chiffrement de faible entropie, utilisée par la défense pour authentifier ses aéronefs alliés durant un conflit armé. 6
  7. 7. Que pensez-vous que votre organisation craint le plus? A. Un déni de service par le groupe Anonymous B. Une fuite de plusieurs dizaines de milliers (ou plus) d'enregistrements personnels C. Un vol de données du département R&D D. La publication d'un faux communiqué de presse sur le site officiel de la société E. Un script remplaçant tous les '1,2' par '1,3' dans vos BDD. 7
  8. 8. La modélisation de menaces… (choisir une réponse) A. La mo…quoi?!?!? B. Je connais mais je n'en vois pas l'utilité. C. C'est sympa mais je n'ai pas le temps. D. J'ai déjà documenté quelques modèles. E. Au petit déj, avant le café! 8
  9. 9. Premières conclusions (probables) 1. Nous ne sommes pas tous d'accord du même avis pour dire ce qui est "grave". 2. Nous ne sommes pas tous du même avis pour la définition d'une injection. 3. Nous ne sommes pas tous du même avis pour la méthode de prévention. 4. Nous ne sommes pas tous du même avis sur la MdM :) 9
  10. 10. Ego-slide • Antonio Fontes • Genève • Consultant Infosécurité • Sécurité des applications et dans le SDLC • Gestion du risque logiciel • Cybercriminalité • http://cddb.ch • OWASP: • Membre du Comité "OWASP Switzerland" • Leader de la section "OWASP Geneva" • https://www.owasp.org 10
  11. 11. Agenda Contexte & motivations Un peu de théorie Etude de cas Conclusions & perspectives 05.juin.2012 11
  12. 12. Agenda Contexte & motivations Un peu de théorie Etude de cas Conclusions & perspectives 05.juin.2012 12
  13. 13. Contexte (trop)dynamique • Axe légal • Axe technologique • Axe organisationnel • Axe économique • Axe socioculturel / politique Ding Wen, développeur d'applications iPhone, 9 ans. 13
  14. 14. Une "menace" omniprésente • Tout système informatique est désormais présenté sous menace constante: • Celles que l'on a oubliées… • Celles dont on peut s'accommoder… • Celles dont la presse nous parle… • Celles dont la loi nous oblige à tenir compte… 14
  15. 15. Pourquoi modéliser? • Un modèle est une "vue" réglementée. Il peut être actualisé. • L'information facilite la prise de décision informée: • Qu'accepte-t-on? Que n'accepte-t-on pas? • Que faut-il absolument faire avec nos moyens limités? • Quelles sont nos priorités? 15
  16. 16. Agenda Contexte & motivations Un peu de théorie Etude de cas Conclusions & perspectives 05.juin.2012 16
  17. 17. « Actif » “Quelque chose appartenant ou contrôlé par l'organisation, dont un bénéfice peut être obtenu.” Particularité: • disponibilité limitée • générateur de valeur • peut-être intangible 05.juin.2012 17
  18. 18. Exemples: Liquidités Machines de production, outils Connaissances, données Systèmes Méthodes Savoir-faire Etc. 05.juin.2012 18
  19. 19. « Vulnérabilité » “Attribut d'un actif dont l'exercice intentionnel ou accidentel pourrait résulter en une infraction à la politique de sécurité ou une brèche de sécurité.” Note: une fonctionnalité légitime d'un système peut devenir, sous certaines conditions, une vulnérabilité. 05.juin.2012 19
  20. 20. Exemples Le papier peut être vulnérable au feu, à l'eau, aux ciseaux… Le corps humain peut être vulnérable à des objets perforants. Un système électrique peut être vulnérable aux surtensions… Une application hautement sécurisée peut être vulnérable à un tremblement de terre. Un mot de passe d'une entropie de 4'096 bits est souvent vulnérable à une arme à feu pointée sur la bonne tempe. 05.juin.2012 20
  21. 21. « Agent de menace » “Quelque chose (objet, événement, être vivant) pouvant exercer une action non autorisée ou indésirable sur un système donné." L'agent requiert: ressource, compétence, accès à un système donné. Ressource? Check Compétence? Check. Accès? Check. 05.juin.2012 21
  22. 22. Exemples Evénements naturels: inondation, événement sismique, … Caractéristiques physiques: poussière, érosion, corrosion, chaleur, … Pannes matérielles: air conditionné, courant électrique, relais de télécommunications, … Perturbations: ondes radio, … Défaillances techniques: bug, saturation, disfonctionnement,… 05.juin.2012 22
  23. 23. Exemples Êtres vivants: Maladroits Distraits Incompétents Vengeurs masqués Robin des bois Collègue jaloux Pirate informatique Crime organisé Suis-je une menace? Terroriste Développeur PHP corrompu Espionnage par un Etat ou une organisation Etc. 05.juin.2012 23
  24. 24. « Impact » “Réduction ou accroissement de la capacité d'une organisation ou d'un individu à atteindre ses objectifs.” L'impact induit une perte ou un profit. Ici, on s'intéresse en priorité aux impacts adverses (donc, générateurs de pertes) 05.juin.2012 24
  25. 25. Exemples Impacts génériques: Dommage à la réputation Diffusion d'information confidentielle ou stratégique Perte financière Perte ou dévaluation d'un savoir-faire ou d'une connaissance Perturbation de l'activité 05.juin.2012 25
  26. 26. Exemples Impacts spécifiques: Mise en danger d'autrui Responsabilité sociale Non-conformité Destruction matérielle … 05.juin.2012 26
  27. 27. Impact financier ou pas? Après extrapolation, tout impact est nécessairement financier. Pour conserver la capacité de diagnostic et de traitement du risque -> impacts catégorisés. L'impact "financier" a lieu lors d'une perte directe nette (vol à l'automate, fraude, transactions, etc.) 27
  28. 28. « Scenario de menace » “Enchaînement spécifique d'actions par un ou plusieurs agents de menace menant à l'atteinte, intentionnelle ou accidentelle d'un état ou d'un événement indésirable pour l'organisation.” 05.juin.2012 28
  29. 29. Exemple Scénario: Un pirate cherche des vulnérabilités dans l'app. X. Le pirate trouve la vulnérabilité 'V'. Le pirate exploite la vulnérabilité V et exfiltre des données confidentielles. Le pirate revend ces données à un concurrent. Quelles conséquences? Quel Impact? Perte de données? Vol de données? Dommage à la réputation? Dommage financier? 05.juin.2012 29
  30. 30. “Risque” “Possibilité qu'une menace donnée exploite les vulnérabilités d'un actif ou d'un groupe d'actifs, et nuise donc à l'organisation.” (ISO27005) Un risque se caractérise par: Une conséquence (impact) (plus ou moins élevé) R= p x i Une probabilité (plus ou moins haute) 05.juin.2012 30
  31. 31. “Risque” OPENOPENOPEN OPENOPENOPEN!! Quel/Qui est l'agent de menace? L'oiseau est-il vulnérable? Quel scénario a-t-on à l'esprit? Quel serait l'impact? Le chat est-il un risque pour cet oiseau? A: Oui B: Non C: ça dépend 05.juin.2012 31
  32. 32. Risque != Danger Le danger suggère la certitude sur deux éléments de l'équation: - l'imminence d'une menace (probabilité proche de 1) - la gravité (conséquence proche de la fatalité) Conclusion: sachons rester zen! 05.juin.2012 32
  33. 33. Qu'est-ce qu'une application web sécurisée? "Une application qui ne va pas nous mettre dans la #@!!()/!" "Une application qui ne met pas en retard le planning!" "La mienne! :)" "Une application sans failles d'injection!" "Une application invulnérable aux attaques!" "Une application communiquant avec SSL!" … 05.juin.2012 33
  34. 34. Qu'est-ce qu'une application sécurisée? 1. Elle se protège, elle et les systèmes et interlocuteurs avec lesquels elle interagit, contre toute action non autorisée de lecture, écriture ou exécution. 2. Ses performances ne peuvent être dégradées pour une autre raison que la rançon du succès. 3. Ses utilisateurs et interlocuteurs ne peuvent nier leurs actions. 4. Elle est un garant des lois et des conformités auxquelles elle est sujette. 05.juin.2012 34
  35. 35. Qu'est-ce qu'une application sécurisée? 1. Elle se protège, elle et les systèmes et interlocuteurs avec lesquels elle interagit, contre toute action non autorisée de lecture, écriture ou Confidentialité Intégrité exécution. 2. Ses performances ne peuvent être dégradées Disponibilité pour une autre raison que la rançon du succès. 3. Ses utilisateurs et interlocuteurs ne peuvent nier Non-répudiation leurs actions. 4. Elle est un garant des lois et Conformité des conformités auxquelles elle est sujette. 05.juin.2012 35
  36. 36. « Application sécurisée »? Chaque organisation a sa propre notion de sécurité. Plateforme de commerce électronique Infrastructure critique Campagne promotionnelle/marketing Plateforme d'échange entre entreprises Communauté, réseau social Banque en ligne Administration en ligne Site web vitrine Etc. 05.juin.2012 36
  37. 37. Le challenge: • Identifier et comprendre la menace: qui peut présenter un comportement adverse et sous quelle forme? • Identifier les mesures les plus efficientes: comment empêche-t-on ce comportement? Comment le détecter? En atténuer l'effet? • Positionner l'organisation: permettre la prise de décision éclairée. 05.juin.2012 37
  38. 38. Agenda Contexte & motivations Un peu de théorie Etude de cas Conclusions & perspectives 05.juin.2012 38
  39. 39. Etude de cas: PLCM (Planificateur en ligne pour consultation médicale) Mission: 1. Alléger les activités de secrétariat pour un groupe de pédiatres actifs dans plusieurs villages. 2. Permettre la planification en ligne 24/24 de consultations 3. Améliorer le mécanisme de triage (symptômes -> urgences) 05.juin.2012 39
  40. 40. PLCM: le concept Cas d'utilisation: Patients: Recherche d'un slot disponible et réservation d'une consultation. Annulation d'une consultation Cabinet: Recherche de cas urgents Pré-diagnostic de patients au moyen d'un questionnaire en ligne. Modification des rendez-vous 05.juin.2012 40
  41. 41. PLCM: le concept Cas d'utilisation: Assurances: Rapport statistique mensuel et anonymisé 05.juin.2012 41
  42. 42. PLCM: le concept Vision: Une application web Les patients réguliers ont un compte permettant la réservation j+1 De l'hébergement de pro Mais le moins cher possible... 05.juin.2012 42
  43. 43. PLCM: le client Le pédiatre contacte une agence web Pouvez-vous me faire ce site? Challenge accepted! 05.juin.2012 43
  44. 44. PLCM: le client Le client achète régulièrement son journal dans la rue… et voit des trucs bizarres Hé! Mr. Sécurité, tu penses quoi de mon projet?? Photo volée sans scrupules sur le mur Facebook de @SPoint 05.juin.2012 44
  45. 45. PLCM: le client The customer comes to Confoo and attends the “web security” talk…. - Hey security guy! What do you think? 05.juin.2012 45
  46. 46. Réputation!!! Script kiddies Contournement de Entropie Code review l'authentification Espionnage! cryptographique Injection SQL Revue deCross-Site code source faible Encodage Scripting!!! Vol de données Hackers! vulnérable Stockage Patients VIP Validation vulnérable de Attaques web modèle Test d'intrusion Il faut un défaillante Configuration Injection LDAP de menaces! vulnérable mot de passe Références Données patient directes non de Non-conformité Vol mot de Données sur médical sécurisées passe des enfants Données personnelles ANONYMOUS!!! 05.juin.2012 46
  47. 47. Modèle de menaces (MdM) (threat analysis and modeling) Un processus, pour identifier et documenter les menaces auxquelles un système est exposé et les mesures à mettre en œuvre pour les contrer, les détecter ou les atténuer. 05.juin.2012 47
  48. 48. Qu'est-ce que le MdM? Un processus que l'on peut répéter et améliorer. Une activité qui a lieu tôt dans le cycle de développement: Durant la conception Optimise le traitement du risque avant la production de code Un processus simple: table, chaises, papier, crayon, pizzas, [remplacer ici par la boisson qui convient] 05.juin.2012 48
  49. 49. Ce que le MdM n'est pas? Ce n'est pas la solution à tous les maux: Ne compense pas l'absence de bonnes pratiques à chaque phase du cycle de développement (conception, implémentation, intégration, maintenance) Ce n'est pas une science exacte: 1 livre couvre officiellement le sujet. Il a été publié en 2004. Par Microsoft. Chacun imagine un modèle différent. 05.juin.2012 49
  50. 50. Qu'est-ce que l'on obtient? Le processus vise à livrer: Les menaces, s'exerçant sur l'application Les scenarios, pouvant résulter en un dommage Les mesures, nécessaires pour bloquer, détecter ou atténuer la survenance de ces scénarios. Globalement: le MdM aide à prioriser les efforts de sécurité 05.juin.2012 50
  51. 51. Contenu typique d'un MdM Description du système et de ses actifs de haute valeur (assets) Description des agents de menace (threat sources) Description des scénarios de menace (threat scenarios) Enumération des contrôles/mesures de sécurité (controls / countermeasures) 05.juin.2012 51
  52. 52. Processus 1. Décrire le système et identifier ses actifs 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 52
  53. 53. 1. Description du système Quels sont les objectifs du système? Quelles sont ses besoins/contraintes de sécurité? (quand les choses sont bien faites, cette étape est déjà documentée!) Illustrer le système (technique dite "DFD") 05.juin.2012 53
  54. 54. 1. Description du système DEMO Diagrammes de flux DFD (dataflow diagram) 05.juin.2012 54
  55. 55. 1. Description du système 05.juin.2012 55
  56. 56. 1. Description du système Source de données (datastore) 05.juin.2012 56
  57. 57. 1. Description du système Processus/ programme (process) 05.juin.2012 57
  58. 58. 1. Description du système Acteur (actor) 05.juin.2012 58
  59. 59. 1. Description du système Flux (flow) 05.juin.2012 59
  60. 60. 1. Description du système Limite de confiance (trust boundary) 05.juin.2012 60
  61. 61. 1. Description du système Délimiteur Identifier les actifs de haute valeur: de confiance (high-value assets) Est-ce que l'on fait confiance aux administrateurs de cette zone? Est-ce que l'on fait confiance aux autres hôtes de cette zone? Peut-on intercepter les communications dans cette zone? Etc. 05.juin.2012 61
  62. 62. 1. Description du système 05.juin.2012 62
  63. 63. 1. Description du système Identifier les actifs de haute valeur: Sources de (high-value assets) données Que souhaiterait-on voler? (confidentialité) Que souhaiterait-on acheter? Que souhaiterait-on lire? Que souhaiterait-on détruire? (intégrité) Que souhaiterait-on modifier? Quelles lois ou réglementations s'appliquent-elles? Les données sortiront-elles du système? 05.juin.2012 63
  64. 64. 1. Description du système 05.juin.2012 64
  65. 65. 1. Description du système Identifier les actifs de haute valeur: Programme (high-value assets) Quel agent souhaiteront-on usurper? Dans quel agent souhaiteront-on modifier la logique? Quel agent a le droit d'accéder à d'autres agents? Des agents de contrôle? Critique? Physique? Des autres organisations? (relais) Un système transactionnel interne? Est-ce grave si l'agent s'arrête? 05.juin.2012 65
  66. 66. 1. Description du système 05.juin.2012 66
  67. 67. 1. Description du système Identifier les actifs de haute valeur: (high-value assets) Acteur Souhaiterait-on usurper un utilisateur? Lequel? Pourquoi? Pour consulter? Pour modifier? Un acteur a-t-il intérêt à pouvoir nier ses actes? Un acteur se connecte-t-il depuis un équipement probablement compromis? Un acteur se connecte-t-il depuis un équipement que certains souhaiteraient compromettre? 05.juin.2012 67
  68. 68. 1. Description du système 05.juin.2012 68
  69. 69. 1. Description du système Identifier les actifs de haute valeur: Flux (high-value assets) Obtient-on quelque chose en interceptant ce trafic? des informations? un mot de passe? Est-ce intéressant de pouvoir modifier ce trafic? Pour affecter des transactions? Quelle est la direction du flux? Est-ce une porte d'entrée dans notre système? (validation) Est-ce un vecteur d'entrée chez un tiers? (encodage) 05.juin.2012 69
  70. 70. 1. Description du système 05.juin.2012 70
  71. 71. 1. Description du système Identifier les actifs de haute valeur: (high-value assets) On refait l'exercice une seconde fois: il y a des choses que l'on n'avait probablement pas compris au premier passage. 05.juin.2012 71
  72. 72. 1. Description du système HVAs: Des mots de passe vont probablement transiter par les flux. L'application alimente le S.I. d'une compagnie d'assurance. Les données sont soumise à réglementation. Pas d'interception de trafic dans le cabinet. Mais on ne sait pas trop si les systèmes sont propres. Quid d'un cheval de Troie? 05.juin.2012 72
  73. 73. 1. Description du système HVAs: 2 flux entrants critiques --> Accroître la validation! 3 flux sortants critiques --> Veiller au traitement d'erreurs et messages 2 acteurs dont le client est à compromettre --> veiller à l'encodage des données! 2 sources de données hautement réglementées --> veiller à respecter les contraintes 2 flux hautement réglementés --> veiller à respecter les contraintes 05.juin.2012 73
  74. 74. 1. Pourquoi utiliser le 'DFD'? Réponse pragmatique: c'est simple à comprendre. Source de Acteur données Flux Programme - User - Database - Call - Service - other system server - Network link - Executable -Partner/supplier - Config file - RPC - DLL -… - Registry -… - Component - Memory - Web service - Queue / stack - Assembly -… -… Process boundary Frontière de File system confiance Network … 05.juin.2012 74
  75. 75. Processus 1. Décrire le système et identifier ses actifs 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 75
  76. 76. 2. Agents de menace Utiliser une liste d'agents formalisée La Direction est censée la connaître (1% des cas). La Direction en ignore l'existence (99% des cas) Souvent, il faut improviser (en se tenant au courant) Un agent est caractérisé par: Son importance (nombre), sa motivation (moyens), l'étendue de son accès au système, sa démarche (ciblée ou opportuniste) 05.juin.2012 76
  77. 77. 2. Agents de menace (générique) Type Source Intensité Exposition Remarque Sources Élevée automatisées (vers) Opportuniste Outils automatisés Élevée (amateurs) Conformité / Loi Modérée Concurrence Faible “Anonymous” Faible Ciblé Interne Faible Espionnage Faible industriel / étatique 05.juin.2012 77
  78. 78. 2. Agents de menace (spécifique) Type Source Intensité Exposition Remarque Systèmes clients Elevée compromis Opportuniste Enfants Elevée Autres cabinets Faible “Anonymous” Faible Tricheurs Faible Ciblé Espionnage Faible économique Conformité Faible Loi 05.juin.2012 78
  79. 79. 2. Agents de menace (spécifique) Type Source Intensité Exposition Remarque Systèmes clients Elevée Elevée Connecté compromis au web Opportuniste Enfants Elevée Elevée Connecté au web Autres cabinets Faible Elevée Connecté au web “Anonymous” Faible Elevée Connecté au web Tricheurs Faible Elevée Connecté Ciblé au web Espionnage Faible Elevée Connecté économique au web Conformité Faible Modérée Données Loi privées + patient 05.juin.2012 79
  80. 80. Processus 1. Décrire le système et identifier ses actifs 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 80
  81. 81. 3. Quels scénarios? Rappel: Le modèle de menaces n'est pas un substitut à la démarche de développement sécurisé! Objectif: Identifier et documenter les pires scénarios (doomsday scenarios) 05.juin.2012 81
  82. 82. 3. Scenarios "doomsday" Un peu d'aide: (Evaluer pour chaque agent de menace) Veut-il/elle voler vos données? Les revendre? Veut-il/elle modifier les données? Veut-il/elle entrer dans le réseau interne? Veut-il/elle entrer chez un tiers grâce à votre réseau? Veut-il/elle ralentir ou paralyser votre activité? Veut-il/elle nier ses actions? Veut-il/elle éviter de payer? Veut-il/elle retirer de l'argent? Veut-il/elle porter atteinte à votre réputation? Veut-il/elle vous dénoncer aux autorités? 05.juin.2012 82
  83. 83. 3. Scenarios "doomsday" Un peu d'aide: (Evaluer pour chaque agent de menace) Veut-il/elle s'amuser avec des programmes de hack? Veut-il/elle accéder à votre système avec un client compromis? …à compléter 05.juin.2012 83
  84. 84. 3. Scenarios "doomsday" Décrire le scénario: Qui déclenche le scénario? (agent) Quelle est son intensité et l'exposition du système? Quel serait l'impact? Vol? Perte? Corruption? Perturbation? Financier? Légal? Réputation? Productivité? Santé? Comment le scénario se déroule-t-il? Décrire ce qu'il se passe quand on crie "Attaque!!" --> l'arbre d'intrusion 05.juin.2012 84
  85. 85. 3. Scenarios "doomsday" Scénario ??? Scénario ??? Scénario … Scénario … 05.juin.2012 85
  86. 86. 3. Scenarios "doomsday" Scénario La liste des patients est volée Scénario La liste des mots de passe est diffusée sur Internet Scénario Un patient substitue son rdv avec celui d'un autre Scénario Un cheval de Troie est injecté dans le réseau de la compagnie d'assurances Scénario Le compte d'accès du médecin est volé et discrètement surveillé par une agence de renseignement. Scénario … Scénario … 05.juin.2012 86
  87. 87. 3. Scenarios "doomsday" Description La liste des patients est volée Source(s) Un autre cabinet ou une autre société intéressée par ces données (intensité faible; exposition élevée) Impact Financier: impact élevé si un autre cabinet l'obtient. Réputation: impact moyen si cela se sait. Chemin La BDD est obtenue grâce à une injection de code: d'intrusion - un paramètre n'a pas été validé correctement #1 - l'injection déclenche une exécution de script côté BDD - les données sont retournées à l'attaquant (soit en ligne directe, soit après écriture dans un fichier temp.) 05.juin.2012 87
  88. 88. 3. Scenarios "doomsday" Chemin La BDD est obtenue depuis l'intérieur du réseau d'intrusion d'hébergement: #2 - L'attaquant s'authentifie dans le système. - L'attaquant copie les données sur un support externe ou les envoie à travers le réseau Chemin L'attaquant obtient l'accès au compte du médecin: d'intrusion -Le mot de passe est deviné ou cassé en force brute #3 - Le mot de passe est intercepté depuis le réseau - Le mot de passe est intercepté depuis le poste Repeat with the other scenarios… d'accès 05.juin.2012 88
  89. 89. 3. Scenarios "doomsday" Attack trees Chemin La BDD est obtenue grâce à une injection de code: d'intrusion #1 - un paramètre n'a pas été validé correctement - l'injection déclenche une exécution de script côté BDD - les données sont retournées à l'attaquant (soit en ligne directe à travers les messages d'erreur, soit après écriture dans un fichier temp.) Paramètre non-validé Injection de code Message Fichier temp d'erreur accessible lisible Vol de la BDD patients 05.juin.2012 89
  90. 90. 3. Scenarios "doomsday" Attack trees Chemin La BDD est obtenue depuis l'intérieur du réseau d'intrusion #2 d'hébergement: - L'attaquant s'authentifie dans le système. - L'attaquant copie les données sur un support externe ou Par les envoie à travers le réseau Par cassage interception Mdp local Accès obtenu physique Paramètre Intrusion non-validé locale Injection de Vol local code Vol de la BDD patients 05.juin.2012 90
  91. 91. 3. Scenarios "doomsday" Attack trees Chemin L'attaquant obtient l'accès au compte du médecin: d'intrusion -Le mot de passe est deviné ou cassé en force brute #3 - Le mot de passe est intercepté depuis le réseau - Le mot de passe est intercepté depuis le poste d'accès Par Par Interception Mdp cassage interception email envoyé en clair Malware Mdp faible Mdp local Accès Interception obtenu physique de trafic Vulnerable Force brute Intrusion Vol parameter d'identifiants locale Code Mdp obtenu Vol local Mdp volé injection Vol de la BDD patients 05.juin.2012 91
  92. 92. 3. Scenarios "doomsday" Arbre Simple d'intrusion #1 password Network sniffing Traffic Weak interception Malware password Known local Physical password intrusion Hacked email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Vol de la BDD patients 05.juin.2012 92
  93. 93. Processus 1. Décrire le système 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 93
  94. 94. 4. Identifier les contrôles Attack tree for Simple scenario #1 password Network sniffing Traffic Weak interception Malware password Known local Physical password intrusion Hacked email Bruteforce Analyse des contremesures attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 94
  95. 95. 4. Identifier les contrôles Attack tree for Simple scenario #1 password Network sniffing - ??? Traffic Weak interception Malware password Known local Physical password intrusion Hacked email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 95
  96. 96. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak interception Malware password Known local Physical password intrusion Hacked email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 96
  97. 97. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - ??? interception Malware password Known local Physical password intrusion Hacked email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 97
  98. 98. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 98
  99. 99. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle d'accès physique email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 99
  100. 100. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle d'accès physique email Bruteforce - ??? attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 100
  101. 101. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle d'accès physique email Bruteforce - Politique de mdp attack Local complexe intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 101
  102. 102. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle d'accès physique email Bruteforce - Politique de mdp attack Local complexe intrusion Stolen Bruteforced Vulnerable - Accès distant via protocole credentials or Guessed parameter chiffré Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 102
  103. 103. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle d'accès physique email Bruteforce - Politique de mdp attack Local complexe intrusion Stolen Bruteforced Vulnerable - Accès distant via protocole credentials or Guessed parameter chiffré Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 103
  104. 104. 4. Identifier les contrôles Attack tree for scenario #1 - Valider les données à tous Traffic Weak les points d'entrée. interception Malware password - Gestion des mises à jour Hacked - Hardening du système email Bruteforce - Contrôle d'accès physique attack - Politique de mdp Stolen complexe credentials Bruteforced or Guessed - Accès distant via protocole chiffré Got cabinet password Patient database is stolen 05.juin.2012 104
  105. 105. 4. Identifier les contrôles Attack tree for scenario #1 - Valider les données à tous les points d'entrée. Traffic Weak interception Malware password - Gestion des mises à jour - Hardening du système Hacked - Contrôle d'accès physique email Bruteforce - Politique de mdp complexe attack - Accès distant via protocole chiffré - Politique de mdp complexe Stolen (webapp) credentials Bruteforced - Pas d'envoi du mdp par email or Guessed - SSL/TLS - Authentification forte Got cabinet - Protection contre force brute password Patient database is stolen 05.juin.2012 105
  106. 106. 4. Identifier les contrôles Attack tree for scenario #1 - Valider les données à tous les points d'entrée. Traffic Weak interception Malware password - Gestion des mises à jour - Hardening du système Hacked - Contrôle d'accès physique email Bruteforce - Politique de mdp complexe attack - Accès distant via protocole chiffré - Politique de mdp complexe Stolen (webapp) credentials Bruteforced - Pas d'envoi du mdp par email or Guessed - SSL/TLS - Authentification forte Got cabinet - Protection contre force brute password Patient database is stolen 05.juin.2012 106
  107. 107. 4. Identifier les contrôles Vol de la BDD patients Contremesures - Valider les données dans les points d'injection arbre d'attaque #1 Contremesures - Maintenir le système à jour et le renforcer arbre d'attaque #2 - Protéger l'accès physique au système - Politique de mdp locaux complexe - Accès distant via protocole chiffré Contremesures - Politique de mdp complexe arbre d'attaque #3 - Pas d'envoi du mdp par email, short lifetime recovery link - SSL/TLS - Authentification forte - Mécanisme anti-force brute 05.juin.2012 107
  108. 108. 4. Identifier les contrôles Scénario La liste des patients est volée Scénario La liste des mots de passe est diffusée sur Internet Scénario Un patient substitue son rdv avec celui d'un autre Scénario Un cheval de Troie est injecté dans le réseau de la compagnie d'assurances Scénario Le compte d'accès du médecin est volé et discrètement surveillé par une agence de renseignement. Scénario … Scénario … 05.juin.2012 108
  109. 109. Processus 1. Décrire le système 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 109
  110. 110. 5. Documenter/mettre à jour le modèle de menace Proposition: 1. Contexte 2. Description du système 1. Diagramme(s) DFD 2. Actifs de haute valeur 3. Agents de menace 4. Scénarios d'intrusion 5. Liste des contremesures 6. Plan d'action 05.juin.2012 110
  111. 111. Processus 1. Décrire le système 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 111
  112. 112. 6. Diffuser le modèle ????? En général, un document infosécurité s'adresse à des professionnels de l'infosécurité. Même si l'on espère très souvent le contraire… A retenir: les destinataires ne comprendront pas le modèle de menace: Présenter les résultats en personne. Parler la bonne langue. Discuter les contrôles proposés: coût vs. Impact sur le scénario 05.juin.2012 112
  113. 113. 6. Diffuser le modèle Pour accroître l'adoption de la méthode: Le plan d'action doit être acceptable. Votre vision est probablement fausse, consultez le client! Ne pas en faire trop: garder une vision globale du risque à l'esprit! L'objectif est d'améliorer avec les moyens du bord, pas de dénoncer les manquements! 05.juin.2012 113
  114. 114. 6. Diffuser le modèle en interne Quels destinataires? Les architectes: certaines recommandations les guideront dans la conception de l'application. Identifiez-les! Les développeurs: pour les curieux uniquement. Pour les autres, ils ont déjà assez à faire. L'équipe sécurité: elle va probablement devoir traduire le document dans la bonne langue-> pour le management (coût/durée), pour les développeurs (tâches) L'équipe qualité: le modèle va pouvoir lui servir de plan de test. 05.juin.2012 114
  115. 115. 6. Diffuser le modèle à l'éditeur Le modèle de menace formalise la préoccupation du client et ses enjeux stratégiques. Il peut être inclus dans le critère d'acceptation des livrables à différentes étapes: • Spécification fonctionnelle de l'application • Contrainte de conformité: "l'application ne doit pas être vulnérable aux attaques suivantes" • Contrainte pour le plan d'assurance qualité: "le plan de test doit évaluer la résistance aux attaques décrites dans le MdM" • Etc. 05.juin.2012 115
  116. 116. Agenda Contexte & motivations Un peu de théorie Etude de cas Conclusions & perspectives 05.juin.2012 116
  117. 117. Aller plus loin… Approche "attaquant": Basée sur le profil de sophistication et mode opératoire des attaquants potentiels. Approche "actifs": Basée sur les actifs de haute valeur du système. Approche "systématique": Application systématique et exhaustive de l'outil STRIDE sur chaque composant de l'architecture. 05.juin.2012 117
  118. 118. Aller plus loin… Varier le niveau de détail des DFDs selon le risque: Application web? Application web + serveur web? Application web + serveur web + système d'exploitation? Application web + serveur web + système d'exploitation + hardware? Etc. Essayer l'approche systématique: Application exhaustive du modèle STRIDE + Outil TAM tool Ajuster le positionnement de l'organisation: Niveau 1: Conformité Niveau 2: Défense what we did Niveau 3: Défense et détection Niveau 4: Défense, détection, contremesure 05.juin.2012 118
  119. 119. Aller plus loin… Points d'injection serveur 05.juin.2012 119
  120. 120. Aller plus loin… Points d'injection client 05.juin.2012 120
  121. 121. Aller plus loin… Points de fuite 05.juin.2012 121
  122. 122. Aller plus loin… Configuration cryptographique 05.juin.2012 122
  123. 123. Aller plus loin… Menaces technologiques 05.juin.2012 123
  124. 124. Aller plus loin… Inception Design Implementation Verification Release Operations Stratégie "Prévention": - Conception et architectures sécurisées - Définition des besoins de sécurité - Sensibilisation/formation à la sécurité des applications web Stratégie "Détection": - Validation de la spécification/cahier des charges - Validation du concept/architecture - Revue de sécurité du code source - Test d'intrusion 05.juin.2012 124
  125. 125. Aller plus loin… STRIDE threat identification tool http://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx DREAD severity assessment tool http://en.wikipedia.org/wiki/DREAD:_Risk_assessment_model OWASP threat risk modeling https://www.owasp.org/index.php/Threat_Risk_Modeling Microsoft SDL design phase activities + TAM tool http://www.microsoft.com/security/sdl/discover/design.aspx 05.juin.2012 125
  126. 126. Conclusion Le modèle de menaces est une opportunité pour traiter le risque au plus tôt: Pas de code source requis Les menaces et contremesures sont aujourd'hui bien identifiées. 05.juin.2012 126
  127. 127. Conclusion ??? Le modèle de menaces est une opportunité pour améliorer la conception: Les recommandations peuvent être transmises à un architecte et incluses comme part entière du cahier des charges de l'application. Le client n'a pas nécessairement besoin de le comprendre. En revanche, l'expert sécurité doit avoir compris le besoin du client… 05.juin.2012 127
  128. 128. Conclusion Le modèle de menaces risque de nous éloigner des préoccupations principales. Garder un œil sur la vue d'ensemble: de quoi veut-on se protéger et pourquoi? Rester simple, et modeste. 05.juin.2012 128
  129. 129. Suivez l'OWASP près de chez vous (et c'est en VF!) France https://www.owasp.org/index.php/France http://lists.owasp.org/mailman/listinfo/owasp-france Belgique https://www.owasp.org/index.php/Belgium http://lists.owasp.org/mailman/listinfo/owasp-belgium Suisse https://www.owasp.org/index.php/Geneva http://lists.owasp.org/mailman/listinfo/owasp-geneva 05.juin.2012 129
  130. 130. Merci! Pour me contacter: email: antonio.fontes@owasp.org twitter: @starbuck3000 Newsletter CDDB Cybermenaces et sécurité Internet: http://cddb.ch Ce support sera publié sur slideshare.net: http://www.slideshare.net/starbuck3000 05.juin.2012 130

Description

Etude de cas - Modélisation des menaces d'une application web

Forum PHP - 2012
Cité Universitaire, Paris

Transcript

  1. 1. Modéliser les menaces d'une application web étude de cas Antonio Fontes antonio.fontes@owasp.org 5 juin 2012 Décharge: aucun chat n'a été blessé ou importuné durant la préparation de ce document.
  2. 2. Quelques questions… 2
  3. 3. Quel interpréteur pourrait être la cible d'une tentative d'injection? (une à plusieurs réponses possibles) A. Interpréteur de requête XPath B. Interpréteur de requête SQL C. Interpréteur de requête LDAP D. Interpréteur de nom de fichier E. Interpréteur de session SMTP F. Tous ceux mentionnés G. Une injé…quoi?? 3
  4. 4. La meilleure méthode pour empêcher une injection SQL? (une à plusieurs réponses possibles) A. Validation de données B. Canonisation puis validation de données C. Encodage de données D. Requête SQL paramétrée E. Canonisation de données F. Validation puis canonisation G. Il faut tout faire!!! 4
  5. 5. Qu'est-ce qui est plus grave? (une réponse autorisée) A. Une injection SQL. (A1) B. Une référence directe non sécurisée. (A4) C. Une clé de chiffrement à entropie basse (A9) 5
  6. 6. Qu'est-ce qui est plus grave? (une réponse autorisée) A. Une injection SQL…sur la page d'accueil du site web de la boucherie du village. B. Une référence directe non sécurisée…sur le lien de consultation en ligne des factures d'un fournisseur national d'énergie. C. Une clé de chiffrement de faible entropie, utilisée par la défense pour authentifier ses aéronefs alliés durant un conflit armé. 6
  7. 7. Que pensez-vous que votre organisation craint le plus? A. Un déni de service par le groupe Anonymous B. Une fuite de plusieurs dizaines de milliers (ou plus) d'enregistrements personnels C. Un vol de données du département R&D D. La publication d'un faux communiqué de presse sur le site officiel de la société E. Un script remplaçant tous les '1,2' par '1,3' dans vos BDD. 7
  8. 8. La modélisation de menaces… (choisir une réponse) A. La mo…quoi?!?!? B. Je connais mais je n'en vois pas l'utilité. C. C'est sympa mais je n'ai pas le temps. D. J'ai déjà documenté quelques modèles. E. Au petit déj, avant le café! 8
  9. 9. Premières conclusions (probables) 1. Nous ne sommes pas tous d'accord du même avis pour dire ce qui est "grave". 2. Nous ne sommes pas tous du même avis pour la définition d'une injection. 3. Nous ne sommes pas tous du même avis pour la méthode de prévention. 4. Nous ne sommes pas tous du même avis sur la MdM :) 9
  10. 10. Ego-slide • Antonio Fontes • Genève • Consultant Infosécurité • Sécurité des applications et dans le SDLC • Gestion du risque logiciel • Cybercriminalité • http://cddb.ch • OWASP: • Membre du Comité "OWASP Switzerland" • Leader de la section "OWASP Geneva" • https://www.owasp.org 10
  11. 11. Agenda Contexte & motivations Un peu de théorie Etude de cas Conclusions & perspectives 05.juin.2012 11
  12. 12. Agenda Contexte & motivations Un peu de théorie Etude de cas Conclusions & perspectives 05.juin.2012 12
  13. 13. Contexte (trop)dynamique • Axe légal • Axe technologique • Axe organisationnel • Axe économique • Axe socioculturel / politique Ding Wen, développeur d'applications iPhone, 9 ans. 13
  14. 14. Une "menace" omniprésente • Tout système informatique est désormais présenté sous menace constante: • Celles que l'on a oubliées… • Celles dont on peut s'accommoder… • Celles dont la presse nous parle… • Celles dont la loi nous oblige à tenir compte… 14
  15. 15. Pourquoi modéliser? • Un modèle est une "vue" réglementée. Il peut être actualisé. • L'information facilite la prise de décision informée: • Qu'accepte-t-on? Que n'accepte-t-on pas? • Que faut-il absolument faire avec nos moyens limités? • Quelles sont nos priorités? 15
  16. 16. Agenda Contexte & motivations Un peu de théorie Etude de cas Conclusions & perspectives 05.juin.2012 16
  17. 17. « Actif » “Quelque chose appartenant ou contrôlé par l'organisation, dont un bénéfice peut être obtenu.” Particularité: • disponibilité limitée • générateur de valeur • peut-être intangible 05.juin.2012 17
  18. 18. Exemples: Liquidités Machines de production, outils Connaissances, données Systèmes Méthodes Savoir-faire Etc. 05.juin.2012 18
  19. 19. « Vulnérabilité » “Attribut d'un actif dont l'exercice intentionnel ou accidentel pourrait résulter en une infraction à la politique de sécurité ou une brèche de sécurité.” Note: une fonctionnalité légitime d'un système peut devenir, sous certaines conditions, une vulnérabilité. 05.juin.2012 19
  20. 20. Exemples Le papier peut être vulnérable au feu, à l'eau, aux ciseaux… Le corps humain peut être vulnérable à des objets perforants. Un système électrique peut être vulnérable aux surtensions… Une application hautement sécurisée peut être vulnérable à un tremblement de terre. Un mot de passe d'une entropie de 4'096 bits est souvent vulnérable à une arme à feu pointée sur la bonne tempe. 05.juin.2012 20
  21. 21. « Agent de menace » “Quelque chose (objet, événement, être vivant) pouvant exercer une action non autorisée ou indésirable sur un système donné." L'agent requiert: ressource, compétence, accès à un système donné. Ressource? Check Compétence? Check. Accès? Check. 05.juin.2012 21
  22. 22. Exemples Evénements naturels: inondation, événement sismique, … Caractéristiques physiques: poussière, érosion, corrosion, chaleur, … Pannes matérielles: air conditionné, courant électrique, relais de télécommunications, … Perturbations: ondes radio, … Défaillances techniques: bug, saturation, disfonctionnement,… 05.juin.2012 22
  23. 23. Exemples Êtres vivants: Maladroits Distraits Incompétents Vengeurs masqués Robin des bois Collègue jaloux Pirate informatique Crime organisé Suis-je une menace? Terroriste Développeur PHP corrompu Espionnage par un Etat ou une organisation Etc. 05.juin.2012 23
  24. 24. « Impact » “Réduction ou accroissement de la capacité d'une organisation ou d'un individu à atteindre ses objectifs.” L'impact induit une perte ou un profit. Ici, on s'intéresse en priorité aux impacts adverses (donc, générateurs de pertes) 05.juin.2012 24
  25. 25. Exemples Impacts génériques: Dommage à la réputation Diffusion d'information confidentielle ou stratégique Perte financière Perte ou dévaluation d'un savoir-faire ou d'une connaissance Perturbation de l'activité 05.juin.2012 25
  26. 26. Exemples Impacts spécifiques: Mise en danger d'autrui Responsabilité sociale Non-conformité Destruction matérielle … 05.juin.2012 26
  27. 27. Impact financier ou pas? Après extrapolation, tout impact est nécessairement financier. Pour conserver la capacité de diagnostic et de traitement du risque -> impacts catégorisés. L'impact "financier" a lieu lors d'une perte directe nette (vol à l'automate, fraude, transactions, etc.) 27
  28. 28. « Scenario de menace » “Enchaînement spécifique d'actions par un ou plusieurs agents de menace menant à l'atteinte, intentionnelle ou accidentelle d'un état ou d'un événement indésirable pour l'organisation.” 05.juin.2012 28
  29. 29. Exemple Scénario: Un pirate cherche des vulnérabilités dans l'app. X. Le pirate trouve la vulnérabilité 'V'. Le pirate exploite la vulnérabilité V et exfiltre des données confidentielles. Le pirate revend ces données à un concurrent. Quelles conséquences? Quel Impact? Perte de données? Vol de données? Dommage à la réputation? Dommage financier? 05.juin.2012 29
  30. 30. “Risque” “Possibilité qu'une menace donnée exploite les vulnérabilités d'un actif ou d'un groupe d'actifs, et nuise donc à l'organisation.” (ISO27005) Un risque se caractérise par: Une conséquence (impact) (plus ou moins élevé) R= p x i Une probabilité (plus ou moins haute) 05.juin.2012 30
  31. 31. “Risque” OPENOPENOPEN OPENOPENOPEN!! Quel/Qui est l'agent de menace? L'oiseau est-il vulnérable? Quel scénario a-t-on à l'esprit? Quel serait l'impact? Le chat est-il un risque pour cet oiseau? A: Oui B: Non C: ça dépend 05.juin.2012 31
  32. 32. Risque != Danger Le danger suggère la certitude sur deux éléments de l'équation: - l'imminence d'une menace (probabilité proche de 1) - la gravité (conséquence proche de la fatalité) Conclusion: sachons rester zen! 05.juin.2012 32
  33. 33. Qu'est-ce qu'une application web sécurisée? "Une application qui ne va pas nous mettre dans la #@!!()/!" "Une application qui ne met pas en retard le planning!" "La mienne! :)" "Une application sans failles d'injection!" "Une application invulnérable aux attaques!" "Une application communiquant avec SSL!" … 05.juin.2012 33
  34. 34. Qu'est-ce qu'une application sécurisée? 1. Elle se protège, elle et les systèmes et interlocuteurs avec lesquels elle interagit, contre toute action non autorisée de lecture, écriture ou exécution. 2. Ses performances ne peuvent être dégradées pour une autre raison que la rançon du succès. 3. Ses utilisateurs et interlocuteurs ne peuvent nier leurs actions. 4. Elle est un garant des lois et des conformités auxquelles elle est sujette. 05.juin.2012 34
  35. 35. Qu'est-ce qu'une application sécurisée? 1. Elle se protège, elle et les systèmes et interlocuteurs avec lesquels elle interagit, contre toute action non autorisée de lecture, écriture ou Confidentialité Intégrité exécution. 2. Ses performances ne peuvent être dégradées Disponibilité pour une autre raison que la rançon du succès. 3. Ses utilisateurs et interlocuteurs ne peuvent nier Non-répudiation leurs actions. 4. Elle est un garant des lois et Conformité des conformités auxquelles elle est sujette. 05.juin.2012 35
  36. 36. « Application sécurisée »? Chaque organisation a sa propre notion de sécurité. Plateforme de commerce électronique Infrastructure critique Campagne promotionnelle/marketing Plateforme d'échange entre entreprises Communauté, réseau social Banque en ligne Administration en ligne Site web vitrine Etc. 05.juin.2012 36
  37. 37. Le challenge: • Identifier et comprendre la menace: qui peut présenter un comportement adverse et sous quelle forme? • Identifier les mesures les plus efficientes: comment empêche-t-on ce comportement? Comment le détecter? En atténuer l'effet? • Positionner l'organisation: permettre la prise de décision éclairée. 05.juin.2012 37
  38. 38. Agenda Contexte & motivations Un peu de théorie Etude de cas Conclusions & perspectives 05.juin.2012 38
  39. 39. Etude de cas: PLCM (Planificateur en ligne pour consultation médicale) Mission: 1. Alléger les activités de secrétariat pour un groupe de pédiatres actifs dans plusieurs villages. 2. Permettre la planification en ligne 24/24 de consultations 3. Améliorer le mécanisme de triage (symptômes -> urgences) 05.juin.2012 39
  40. 40. PLCM: le concept Cas d'utilisation: Patients: Recherche d'un slot disponible et réservation d'une consultation. Annulation d'une consultation Cabinet: Recherche de cas urgents Pré-diagnostic de patients au moyen d'un questionnaire en ligne. Modification des rendez-vous 05.juin.2012 40
  41. 41. PLCM: le concept Cas d'utilisation: Assurances: Rapport statistique mensuel et anonymisé 05.juin.2012 41
  42. 42. PLCM: le concept Vision: Une application web Les patients réguliers ont un compte permettant la réservation j+1 De l'hébergement de pro Mais le moins cher possible... 05.juin.2012 42
  43. 43. PLCM: le client Le pédiatre contacte une agence web Pouvez-vous me faire ce site? Challenge accepted! 05.juin.2012 43
  44. 44. PLCM: le client Le client achète régulièrement son journal dans la rue… et voit des trucs bizarres Hé! Mr. Sécurité, tu penses quoi de mon projet?? Photo volée sans scrupules sur le mur Facebook de @SPoint 05.juin.2012 44
  45. 45. PLCM: le client The customer comes to Confoo and attends the “web security” talk…. - Hey security guy! What do you think? 05.juin.2012 45
  46. 46. Réputation!!! Script kiddies Contournement de Entropie Code review l'authentification Espionnage! cryptographique Injection SQL Revue deCross-Site code source faible Encodage Scripting!!! Vol de données Hackers! vulnérable Stockage Patients VIP Validation vulnérable de Attaques web modèle Test d'intrusion Il faut un défaillante Configuration Injection LDAP de menaces! vulnérable mot de passe Références Données patient directes non de Non-conformité Vol mot de Données sur médical sécurisées passe des enfants Données personnelles ANONYMOUS!!! 05.juin.2012 46
  47. 47. Modèle de menaces (MdM) (threat analysis and modeling) Un processus, pour identifier et documenter les menaces auxquelles un système est exposé et les mesures à mettre en œuvre pour les contrer, les détecter ou les atténuer. 05.juin.2012 47
  48. 48. Qu'est-ce que le MdM? Un processus que l'on peut répéter et améliorer. Une activité qui a lieu tôt dans le cycle de développement: Durant la conception Optimise le traitement du risque avant la production de code Un processus simple: table, chaises, papier, crayon, pizzas, [remplacer ici par la boisson qui convient] 05.juin.2012 48
  49. 49. Ce que le MdM n'est pas? Ce n'est pas la solution à tous les maux: Ne compense pas l'absence de bonnes pratiques à chaque phase du cycle de développement (conception, implémentation, intégration, maintenance) Ce n'est pas une science exacte: 1 livre couvre officiellement le sujet. Il a été publié en 2004. Par Microsoft. Chacun imagine un modèle différent. 05.juin.2012 49
  50. 50. Qu'est-ce que l'on obtient? Le processus vise à livrer: Les menaces, s'exerçant sur l'application Les scenarios, pouvant résulter en un dommage Les mesures, nécessaires pour bloquer, détecter ou atténuer la survenance de ces scénarios. Globalement: le MdM aide à prioriser les efforts de sécurité 05.juin.2012 50
  51. 51. Contenu typique d'un MdM Description du système et de ses actifs de haute valeur (assets) Description des agents de menace (threat sources) Description des scénarios de menace (threat scenarios) Enumération des contrôles/mesures de sécurité (controls / countermeasures) 05.juin.2012 51
  52. 52. Processus 1. Décrire le système et identifier ses actifs 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 52
  53. 53. 1. Description du système Quels sont les objectifs du système? Quelles sont ses besoins/contraintes de sécurité? (quand les choses sont bien faites, cette étape est déjà documentée!) Illustrer le système (technique dite "DFD") 05.juin.2012 53
  54. 54. 1. Description du système DEMO Diagrammes de flux DFD (dataflow diagram) 05.juin.2012 54
  55. 55. 1. Description du système 05.juin.2012 55
  56. 56. 1. Description du système Source de données (datastore) 05.juin.2012 56
  57. 57. 1. Description du système Processus/ programme (process) 05.juin.2012 57
  58. 58. 1. Description du système Acteur (actor) 05.juin.2012 58
  59. 59. 1. Description du système Flux (flow) 05.juin.2012 59
  60. 60. 1. Description du système Limite de confiance (trust boundary) 05.juin.2012 60
  61. 61. 1. Description du système Délimiteur Identifier les actifs de haute valeur: de confiance (high-value assets) Est-ce que l'on fait confiance aux administrateurs de cette zone? Est-ce que l'on fait confiance aux autres hôtes de cette zone? Peut-on intercepter les communications dans cette zone? Etc. 05.juin.2012 61
  62. 62. 1. Description du système 05.juin.2012 62
  63. 63. 1. Description du système Identifier les actifs de haute valeur: Sources de (high-value assets) données Que souhaiterait-on voler? (confidentialité) Que souhaiterait-on acheter? Que souhaiterait-on lire? Que souhaiterait-on détruire? (intégrité) Que souhaiterait-on modifier? Quelles lois ou réglementations s'appliquent-elles? Les données sortiront-elles du système? 05.juin.2012 63
  64. 64. 1. Description du système 05.juin.2012 64
  65. 65. 1. Description du système Identifier les actifs de haute valeur: Programme (high-value assets) Quel agent souhaiteront-on usurper? Dans quel agent souhaiteront-on modifier la logique? Quel agent a le droit d'accéder à d'autres agents? Des agents de contrôle? Critique? Physique? Des autres organisations? (relais) Un système transactionnel interne? Est-ce grave si l'agent s'arrête? 05.juin.2012 65
  66. 66. 1. Description du système 05.juin.2012 66
  67. 67. 1. Description du système Identifier les actifs de haute valeur: (high-value assets) Acteur Souhaiterait-on usurper un utilisateur? Lequel? Pourquoi? Pour consulter? Pour modifier? Un acteur a-t-il intérêt à pouvoir nier ses actes? Un acteur se connecte-t-il depuis un équipement probablement compromis? Un acteur se connecte-t-il depuis un équipement que certains souhaiteraient compromettre? 05.juin.2012 67
  68. 68. 1. Description du système 05.juin.2012 68
  69. 69. 1. Description du système Identifier les actifs de haute valeur: Flux (high-value assets) Obtient-on quelque chose en interceptant ce trafic? des informations? un mot de passe? Est-ce intéressant de pouvoir modifier ce trafic? Pour affecter des transactions? Quelle est la direction du flux? Est-ce une porte d'entrée dans notre système? (validation) Est-ce un vecteur d'entrée chez un tiers? (encodage) 05.juin.2012 69
  70. 70. 1. Description du système 05.juin.2012 70
  71. 71. 1. Description du système Identifier les actifs de haute valeur: (high-value assets) On refait l'exercice une seconde fois: il y a des choses que l'on n'avait probablement pas compris au premier passage. 05.juin.2012 71
  72. 72. 1. Description du système HVAs: Des mots de passe vont probablement transiter par les flux. L'application alimente le S.I. d'une compagnie d'assurance. Les données sont soumise à réglementation. Pas d'interception de trafic dans le cabinet. Mais on ne sait pas trop si les systèmes sont propres. Quid d'un cheval de Troie? 05.juin.2012 72
  73. 73. 1. Description du système HVAs: 2 flux entrants critiques --> Accroître la validation! 3 flux sortants critiques --> Veiller au traitement d'erreurs et messages 2 acteurs dont le client est à compromettre --> veiller à l'encodage des données! 2 sources de données hautement réglementées --> veiller à respecter les contraintes 2 flux hautement réglementés --> veiller à respecter les contraintes 05.juin.2012 73
  74. 74. 1. Pourquoi utiliser le 'DFD'? Réponse pragmatique: c'est simple à comprendre. Source de Acteur données Flux Programme - User - Database - Call - Service - other system server - Network link - Executable -Partner/supplier - Config file - RPC - DLL -… - Registry -… - Component - Memory - Web service - Queue / stack - Assembly -… -… Process boundary Frontière de File system confiance Network … 05.juin.2012 74
  75. 75. Processus 1. Décrire le système et identifier ses actifs 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 75
  76. 76. 2. Agents de menace Utiliser une liste d'agents formalisée La Direction est censée la connaître (1% des cas). La Direction en ignore l'existence (99% des cas) Souvent, il faut improviser (en se tenant au courant) Un agent est caractérisé par: Son importance (nombre), sa motivation (moyens), l'étendue de son accès au système, sa démarche (ciblée ou opportuniste) 05.juin.2012 76
  77. 77. 2. Agents de menace (générique) Type Source Intensité Exposition Remarque Sources Élevée automatisées (vers) Opportuniste Outils automatisés Élevée (amateurs) Conformité / Loi Modérée Concurrence Faible “Anonymous” Faible Ciblé Interne Faible Espionnage Faible industriel / étatique 05.juin.2012 77
  78. 78. 2. Agents de menace (spécifique) Type Source Intensité Exposition Remarque Systèmes clients Elevée compromis Opportuniste Enfants Elevée Autres cabinets Faible “Anonymous” Faible Tricheurs Faible Ciblé Espionnage Faible économique Conformité Faible Loi 05.juin.2012 78
  79. 79. 2. Agents de menace (spécifique) Type Source Intensité Exposition Remarque Systèmes clients Elevée Elevée Connecté compromis au web Opportuniste Enfants Elevée Elevée Connecté au web Autres cabinets Faible Elevée Connecté au web “Anonymous” Faible Elevée Connecté au web Tricheurs Faible Elevée Connecté Ciblé au web Espionnage Faible Elevée Connecté économique au web Conformité Faible Modérée Données Loi privées + patient 05.juin.2012 79
  80. 80. Processus 1. Décrire le système et identifier ses actifs 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 80
  81. 81. 3. Quels scénarios? Rappel: Le modèle de menaces n'est pas un substitut à la démarche de développement sécurisé! Objectif: Identifier et documenter les pires scénarios (doomsday scenarios) 05.juin.2012 81
  82. 82. 3. Scenarios "doomsday" Un peu d'aide: (Evaluer pour chaque agent de menace) Veut-il/elle voler vos données? Les revendre? Veut-il/elle modifier les données? Veut-il/elle entrer dans le réseau interne? Veut-il/elle entrer chez un tiers grâce à votre réseau? Veut-il/elle ralentir ou paralyser votre activité? Veut-il/elle nier ses actions? Veut-il/elle éviter de payer? Veut-il/elle retirer de l'argent? Veut-il/elle porter atteinte à votre réputation? Veut-il/elle vous dénoncer aux autorités? 05.juin.2012 82
  83. 83. 3. Scenarios "doomsday" Un peu d'aide: (Evaluer pour chaque agent de menace) Veut-il/elle s'amuser avec des programmes de hack? Veut-il/elle accéder à votre système avec un client compromis? …à compléter 05.juin.2012 83
  84. 84. 3. Scenarios "doomsday" Décrire le scénario: Qui déclenche le scénario? (agent) Quelle est son intensité et l'exposition du système? Quel serait l'impact? Vol? Perte? Corruption? Perturbation? Financier? Légal? Réputation? Productivité? Santé? Comment le scénario se déroule-t-il? Décrire ce qu'il se passe quand on crie "Attaque!!" --> l'arbre d'intrusion 05.juin.2012 84
  85. 85. 3. Scenarios "doomsday" Scénario ??? Scénario ??? Scénario … Scénario … 05.juin.2012 85
  86. 86. 3. Scenarios "doomsday" Scénario La liste des patients est volée Scénario La liste des mots de passe est diffusée sur Internet Scénario Un patient substitue son rdv avec celui d'un autre Scénario Un cheval de Troie est injecté dans le réseau de la compagnie d'assurances Scénario Le compte d'accès du médecin est volé et discrètement surveillé par une agence de renseignement. Scénario … Scénario … 05.juin.2012 86
  87. 87. 3. Scenarios "doomsday" Description La liste des patients est volée Source(s) Un autre cabinet ou une autre société intéressée par ces données (intensité faible; exposition élevée) Impact Financier: impact élevé si un autre cabinet l'obtient. Réputation: impact moyen si cela se sait. Chemin La BDD est obtenue grâce à une injection de code: d'intrusion - un paramètre n'a pas été validé correctement #1 - l'injection déclenche une exécution de script côté BDD - les données sont retournées à l'attaquant (soit en ligne directe, soit après écriture dans un fichier temp.) 05.juin.2012 87
  88. 88. 3. Scenarios "doomsday" Chemin La BDD est obtenue depuis l'intérieur du réseau d'intrusion d'hébergement: #2 - L'attaquant s'authentifie dans le système. - L'attaquant copie les données sur un support externe ou les envoie à travers le réseau Chemin L'attaquant obtient l'accès au compte du médecin: d'intrusion -Le mot de passe est deviné ou cassé en force brute #3 - Le mot de passe est intercepté depuis le réseau - Le mot de passe est intercepté depuis le poste Repeat with the other scenarios… d'accès 05.juin.2012 88
  89. 89. 3. Scenarios "doomsday" Attack trees Chemin La BDD est obtenue grâce à une injection de code: d'intrusion #1 - un paramètre n'a pas été validé correctement - l'injection déclenche une exécution de script côté BDD - les données sont retournées à l'attaquant (soit en ligne directe à travers les messages d'erreur, soit après écriture dans un fichier temp.) Paramètre non-validé Injection de code Message Fichier temp d'erreur accessible lisible Vol de la BDD patients 05.juin.2012 89
  90. 90. 3. Scenarios "doomsday" Attack trees Chemin La BDD est obtenue depuis l'intérieur du réseau d'intrusion #2 d'hébergement: - L'attaquant s'authentifie dans le système. - L'attaquant copie les données sur un support externe ou Par les envoie à travers le réseau Par cassage interception Mdp local Accès obtenu physique Paramètre Intrusion non-validé locale Injection de Vol local code Vol de la BDD patients 05.juin.2012 90
  91. 91. 3. Scenarios "doomsday" Attack trees Chemin L'attaquant obtient l'accès au compte du médecin: d'intrusion -Le mot de passe est deviné ou cassé en force brute #3 - Le mot de passe est intercepté depuis le réseau - Le mot de passe est intercepté depuis le poste d'accès Par Par Interception Mdp cassage interception email envoyé en clair Malware Mdp faible Mdp local Accès Interception obtenu physique de trafic Vulnerable Force brute Intrusion Vol parameter d'identifiants locale Code Mdp obtenu Vol local Mdp volé injection Vol de la BDD patients 05.juin.2012 91
  92. 92. 3. Scenarios "doomsday" Arbre Simple d'intrusion #1 password Network sniffing Traffic Weak interception Malware password Known local Physical password intrusion Hacked email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Vol de la BDD patients 05.juin.2012 92
  93. 93. Processus 1. Décrire le système 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 93
  94. 94. 4. Identifier les contrôles Attack tree for Simple scenario #1 password Network sniffing Traffic Weak interception Malware password Known local Physical password intrusion Hacked email Bruteforce Analyse des contremesures attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 94
  95. 95. 4. Identifier les contrôles Attack tree for Simple scenario #1 password Network sniffing - ??? Traffic Weak interception Malware password Known local Physical password intrusion Hacked email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 95
  96. 96. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak interception Malware password Known local Physical password intrusion Hacked email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 96
  97. 97. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - ??? interception Malware password Known local Physical password intrusion Hacked email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 97
  98. 98. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 98
  99. 99. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle d'accès physique email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 99
  100. 100. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle d'accès physique email Bruteforce - ??? attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 100
  101. 101. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle d'accès physique email Bruteforce - Politique de mdp attack Local complexe intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 101
  102. 102. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle d'accès physique email Bruteforce - Politique de mdp attack Local complexe intrusion Stolen Bruteforced Vulnerable - Accès distant via protocole credentials or Guessed parameter chiffré Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 102
  103. 103. 4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points d'entrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle d'accès physique email Bruteforce - Politique de mdp attack Local complexe intrusion Stolen Bruteforced Vulnerable - Accès distant via protocole credentials or Guessed parameter chiffré Local Code stealing Got cabinet injection password Patient database is stolen 05.juin.2012 103
  104. 104. 4. Identifier les contrôles Attack tree for scenario #1 - Valider les données à tous Traffic Weak les points d'entrée. interception Malware password - Gestion des mises à jour Hacked - Hardening du système email Bruteforce - Contrôle d'accès physique attack - Politique de mdp Stolen complexe credentials Bruteforced or Guessed - Accès distant via protocole chiffré Got cabinet password Patient database is stolen 05.juin.2012 104
  105. 105. 4. Identifier les contrôles Attack tree for scenario #1 - Valider les données à tous les points d'entrée. Traffic Weak interception Malware password - Gestion des mises à jour - Hardening du système Hacked - Contrôle d'accès physique email Bruteforce - Politique de mdp complexe attack - Accès distant via protocole chiffré - Politique de mdp complexe Stolen (webapp) credentials Bruteforced - Pas d'envoi du mdp par email or Guessed - SSL/TLS - Authentification forte Got cabinet - Protection contre force brute password Patient database is stolen 05.juin.2012 105
  106. 106. 4. Identifier les contrôles Attack tree for scenario #1 - Valider les données à tous les points d'entrée. Traffic Weak interception Malware password - Gestion des mises à jour - Hardening du système Hacked - Contrôle d'accès physique email Bruteforce - Politique de mdp complexe attack - Accès distant via protocole chiffré - Politique de mdp complexe Stolen (webapp) credentials Bruteforced - Pas d'envoi du mdp par email or Guessed - SSL/TLS - Authentification forte Got cabinet - Protection contre force brute password Patient database is stolen 05.juin.2012 106
  107. 107. 4. Identifier les contrôles Vol de la BDD patients Contremesures - Valider les données dans les points d'injection arbre d'attaque #1 Contremesures - Maintenir le système à jour et le renforcer arbre d'attaque #2 - Protéger l'accès physique au système - Politique de mdp locaux complexe - Accès distant via protocole chiffré Contremesures - Politique de mdp complexe arbre d'attaque #3 - Pas d'envoi du mdp par email, short lifetime recovery link - SSL/TLS - Authentification forte - Mécanisme anti-force brute 05.juin.2012 107
  108. 108. 4. Identifier les contrôles Scénario La liste des patients est volée Scénario La liste des mots de passe est diffusée sur Internet Scénario Un patient substitue son rdv avec celui d'un autre Scénario Un cheval de Troie est injecté dans le réseau de la compagnie d'assurances Scénario Le compte d'accès du médecin est volé et discrètement surveillé par une agence de renseignement. Scénario … Scénario … 05.juin.2012 108
  109. 109. Processus 1. Décrire le système 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 109
  110. 110. 5. Documenter/mettre à jour le modèle de menace Proposition: 1. Contexte 2. Description du système 1. Diagramme(s) DFD 2. Actifs de haute valeur 3. Agents de menace 4. Scénarios d'intrusion 5. Liste des contremesures 6. Plan d'action 05.juin.2012 110
  111. 111. Processus 1. Décrire le système 2. Identifier les agents de menace 3. Identifier les scénarios de menace 4. Identifier les contremesures 5. Documenter/mettre à jour le modèle 6. Diffuser le modèle 05.juin.2012 111
  112. 112. 6. Diffuser le modèle ????? En général, un document infosécurité s'adresse à des professionnels de l'infosécurité. Même si l'on espère très souvent le contraire… A retenir: les destinataires ne comprendront pas le modèle de menace: Présenter les résultats en personne. Parler la bonne langue. Discuter les contrôles proposés: coût vs. Impact sur le scénario 05.juin.2012 112
  113. 113. 6. Diffuser le modèle Pour accroître l'adoption de la méthode: Le plan d'action doit être acceptable. Votre vision est probablement fausse, consultez le client! Ne pas en faire trop: garder une vision globale du risque à l'esprit! L'objectif est d'améliorer avec les moyens du bord, pas de dénoncer les manquements! 05.juin.2012 113
  114. 114. 6. Diffuser le modèle en interne Quels destinataires? Les architectes: certaines recommandations les guideront dans la conception de l'application. Identifiez-les! Les développeurs: pour les curieux uniquement. Pour les autres, ils ont déjà assez à faire. L'équipe sécurité: elle va probablement devoir traduire le document dans la bonne langue-> pour le management (coût/durée), pour les développeurs (tâches) L'équipe qualité: le modèle va pouvoir lui servir de plan de test. 05.juin.2012 114
  115. 115. 6. Diffuser le modèle à l'éditeur Le modèle de menace formalise la préoccupation du client et ses enjeux stratégiques. Il peut être inclus dans le critère d'acceptation des livrables à différentes étapes: • Spécification fonctionnelle de l'application • Contrainte de conformité: "l'application ne doit pas être vulnérable aux attaques suivantes" • Contrainte pour le plan d'assurance qualité: "le plan de test doit évaluer la résistance aux attaques décrites dans le MdM" • Etc. 05.juin.2012 115
  116. 116. Agenda Contexte & motivations Un peu de théorie Etude de cas Conclusions & perspectives 05.juin.2012 116
  117. 117. Aller plus loin… Approche "attaquant": Basée sur le profil de sophistication et mode opératoire des attaquants potentiels. Approche "actifs": Basée sur les actifs de haute valeur du système. Approche "systématique": Application systématique et exhaustive de l'outil STRIDE sur chaque composant de l'architecture. 05.juin.2012 117
  118. 118. Aller plus loin… Varier le niveau de détail des DFDs selon le risque: Application web? Application web + serveur web? Application web + serveur web + système d'exploitation? Application web + serveur web + système d'exploitation + hardware? Etc. Essayer l'approche systématique: Application exhaustive du modèle STRIDE + Outil TAM tool Ajuster le positionnement de l'organisation: Niveau 1: Conformité Niveau 2: Défense what we did Niveau 3: Défense et détection Niveau 4: Défense, détection, contremesure 05.juin.2012 118
  119. 119. Aller plus loin… Points d'injection serveur 05.juin.2012 119
  120. 120. Aller plus loin… Points d'injection client 05.juin.2012 120
  121. 121. Aller plus loin… Points de fuite 05.juin.2012 121
  122. 122. Aller plus loin… Configuration cryptographique 05.juin.2012 122
  123. 123. Aller plus loin… Menaces technologiques 05.juin.2012 123
  124. 124. Aller plus loin… Inception Design Implementation Verification Release Operations Stratégie "Prévention": - Conception et architectures sécurisées - Définition des besoins de sécurité - Sensibilisation/formation à la sécurité des applications web Stratégie "Détection": - Validation de la spécification/cahier des charges - Validation du concept/architecture - Revue de sécurité du code source - Test d'intrusion 05.juin.2012 124
  125. 125. Aller plus loin… STRIDE threat identification tool http://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx DREAD severity assessment tool http://en.wikipedia.org/wiki/DREAD:_Risk_assessment_model OWASP threat risk modeling https://www.owasp.org/index.php/Threat_Risk_Modeling Microsoft SDL design phase activities + TAM tool http://www.microsoft.com/security/sdl/discover/design.aspx 05.juin.2012 125
  126. 126. Conclusion Le modèle de menaces est une opportunité pour traiter le risque au plus tôt: Pas de code source requis Les menaces et contremesures sont aujourd'hui bien identifiées. 05.juin.2012 126
  127. 127. Conclusion ??? Le modèle de menaces est une opportunité pour améliorer la conception: Les recommandations peuvent être transmises à un architecte et incluses comme part entière du cahier des charges de l'application. Le client n'a pas nécessairement besoin de le comprendre. En revanche, l'expert sécurité doit avoir compris le besoin du client… 05.juin.2012 127
  128. 128. Conclusion Le modèle de menaces risque de nous éloigner des préoccupations principales. Garder un œil sur la vue d'ensemble: de quoi veut-on se protéger et pourquoi? Rester simple, et modeste. 05.juin.2012 128
  129. 129. Suivez l'OWASP près de chez vous (et c'est en VF!) France https://www.owasp.org/index.php/France http://lists.owasp.org/mailman/listinfo/owasp-france Belgique https://www.owasp.org/index.php/Belgium http://lists.owasp.org/mailman/listinfo/owasp-belgium Suisse https://www.owasp.org/index.php/Geneva http://lists.owasp.org/mailman/listinfo/owasp-geneva 05.juin.2012 129
  130. 130. Merci! Pour me contacter: email: antonio.fontes@owasp.org twitter: @starbuck3000 Newsletter CDDB Cybermenaces et sécurité Internet: http://cddb.ch Ce support sera publié sur slideshare.net: http://www.slideshare.net/starbuck3000 05.juin.2012 130

More Related Content

Related Books

Free with a 30 day trial from Scribd

See all

×