Modéliser les menaces d'une application web

Modéliser les menaces dune application web étude de cas Antonio Fontes antonio.fontes@owasp.org 5 juin 2012Décharge: aucun chat na été blessé ou importunédurant la préparation de ce document.

Quelques questions… 2

Quel interpréteur pourrait être la cible dune tentative dinjection?(une à plusieurs réponses possibles)A. Interpréteur de requête XPathB. Interpréteur de requête SQLC. Interpréteur de requête LDAPD. Interpréteur de nom de fichierE. Interpréteur de session SMTPF. Tous ceux mentionnésG. Une injé…quoi?? 3

La meilleure méthode pourempêcher une injection SQL?(une à plusieurs réponses possibles)A. Validation de donnéesB. Canonisation puis validation de donnéesC. Encodage de donnéesD. Requête SQL paramétréeE. Canonisation de donnéesF. Validation puis canonisationG. Il faut tout faire!!! 4

Quest-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

Quest-ce qui est plus grave?(une réponse autorisée)A. Une injection SQL…sur la page daccueil 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 dun 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

Que pensez-vous que votre organisation craint le plus?A. Un déni de service par le groupe AnonymousB. Une fuite de plusieurs dizaines de milliers (ou plus) denregistrements personnelsC. Un vol de données du département R&DD. La publication dun 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

La modélisation de menaces…(choisir une réponse)A. La mo…quoi?!?!?B. Je connais mais je nen vois pas lutilité.C. Cest sympa mais je nai pas le temps.D. Jai déjà documenté quelques modèles.E. Au petit déj, avant le café! 8

Premières conclusions (probables)1. Nous ne sommes pas tous daccord du même avis pour dire ce qui est "grave".2. Nous ne sommes pas tous du même avis pour la définition dune 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

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

AgendaContexte & motivationsUn peu de théorieEtude de casConclusions & perspectives05.juin.2012 11

Contexte (trop)dynamique• Axe légal• Axe technologique• Axe organisationnel• Axe économique• Axe socioculturel / politique Ding Wen, développeur dapplications iPhone, 9 ans. 13

Une "menace" omniprésente• Tout système informatique est désormais présenté sous menace constante: • Celles que lon a oubliées… • Celles dont on peut saccommoder… • Celles dont la presse nous parle… • Celles dont la loi nous oblige à tenir compte… 14

Pourquoi modéliser?• Un modèle est une "vue" réglementée. Il peut être actualisé.• Linformation facilite la prise de décision informée: • Quaccepte-t-on? Que naccepte-t-on pas? • Que faut-il absolument faire avec nos moyens limités? • Quelles sont nos priorités? 15

« Actif »“Quelque chose appartenant ou contrôlé par lorganisation, dont un bénéfice peut être obtenu.”Particularité:• disponibilité limitée• générateur de valeur• peut-être intangible05.juin.2012 17

Exemples:LiquiditésMachines de production, outilsConnaissances, donnéesSystèmesMéthodesSavoir-faireEtc.05.juin.2012 18

« Vulnérabilité »“Attribut dun actif dont lexercice 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 dun système peut devenir, sous certaines conditions, une vulnérabilité.05.juin.2012 19

Exemples Le papier peut être vulnérable au feu, à leau, 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 dune entropie de 4096 bits est souvent vulnérable à une arme à feu pointée sur la bonne tempe.05.juin.2012 20

« 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é."Lagent requiert: ressource, compétence, accès à un système donné. Ressource? Check Compétence? Check. Accès? Check.05.juin.2012 21

ExemplesEvé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

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

« Impact »“Réduction ou accroissement de la capacité dune organisation ou dun individu à atteindre ses objectifs.”Limpact induit une perte ou un profit.Ici, on sintéresse en priorité aux impacts adverses (donc, générateurs de pertes)05.juin.2012 24

ExemplesImpacts génériques: Dommage à la réputation Diffusion dinformation confidentielle ou stratégique Perte financière Perte ou dévaluation dun savoir-faire ou dune connaissance Perturbation de lactivité05.juin.2012 25

ExemplesImpacts spécifiques: Mise en danger dautrui Responsabilité sociale Non-conformité Destruction matérielle …05.juin.2012 26

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. Limpact "financier" a lieu lors dune perte directe nette (vol à lautomate, fraude, transactions, etc.) 27

« Scenario de menace »“Enchaînement spécifique dactions par un ou plusieurs agents de menace menant à latteinte, intentionnelle ou accidentelle dun état ou dun événement indésirable pour lorganisation.”05.juin.2012 28

ExempleScénario: Un pirate cherche des vulnérabilités dans lapp. 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

“Risque”“Possibilité quune menace donnée exploite les vulnérabilités dun actif ou dun groupe dactifs, et nuise donc à lorganisation.” (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

“Risque” OPENOPENOPEN OPENOPENOPEN!! Quel/Qui est lagent de menace? Loiseau est-il vulnérable? Quel scénario a-t-on à lesprit? Quel serait limpact? Le chat est-il un risque pour cet oiseau? A: Oui B: Non C: ça dépend05.juin.2012 31

Risque != DangerLe danger suggère la certitude sur deux éléments de léquation: - limminence dune menace (probabilité proche de 1) - la gravité (conséquence proche de la fatalité) Conclusion: sachons rester zen!05.juin.2012 32

Quest-ce quune 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 dinjection!""Une application invulnérable aux attaques!""Une application communiquant avec SSL!" …05.juin.2012 33

Quest-ce quune 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

Quest-ce quune 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

« 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

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 leffet?• Positionner lorganisation: permettre la prise de décision éclairée.05.juin.2012 37

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

PLCM: le conceptCas dutilisation: Patients: Recherche dun slot disponible et réservation dune consultation. Annulation dune consultation Cabinet: Recherche de cas urgents Pré-diagnostic de patients au moyen dun questionnaire en ligne. Modification des rendez-vous05.juin.2012 40

PLCM: le conceptCas dutilisation: Assurances: Rapport statistique mensuel et anonymisé05.juin.2012 41

PLCM: le conceptVision: Une application web Les patients réguliers ont un compte permettant la réservation j+1 De lhébergement de pro Mais le moins cher possible...05.juin.2012 42

PLCM: le clientLe pédiatre contacte une agence web Pouvez-vous me faire ce site? Challenge accepted!05.juin.2012 43

PLCM: le clientLe 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 @SPoint05.juin.2012 44

PLCM: le clientThe customer comes to Confoo and attends the “web security” talk…. - Hey security guy! What do you think?05.juin.2012 45

Réputation!!! Script kiddies Contournement de EntropieCode review lauthentification Espionnage! cryptographique Injection SQL Revue deCross-Site code source faible Encodage Scripting!!! Vol de données Hackers! vulnérable Stockage Patients VIPValidation vulnérable de Attaques web modèle Test dintrusion Il faut undéfaillante Configuration Injection LDAP de menaces! vulnérable mot de passeRéférences Données patientdirectes non de Non-conformité Vol mot de Données sur médicalsécurisées passe des enfants Données personnelles ANONYMOUS!!!05.juin.2012 46

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

Quest-ce que le MdM?Un processus que lon 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 codeUn processus simple: table, chaises, papier, crayon, pizzas, [remplacer ici par la boisson qui convient]05.juin.2012 48

Ce que le MdM nest pas?Ce nest pas la solution à tous les maux: Ne compense pas labsence de bonnes pratiques à chaque phase du cycle de développement (conception, implémentation, intégration, maintenance)Ce nest 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

Quest-ce que lon obtient?Le processus vise à livrer: Les menaces, sexerçant sur lapplication 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

Contenu typique dun MdMDescription 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

Processus1. Décrire le système et identifier ses actifs2. Identifier les agents de menace3. Identifier les scénarios de menace4. Identifier les contremesures5. Documenter/mettre à jour le modèle6. Diffuser le modèle05.juin.2012 52

1. Description du systèmeQuels 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

1. Description du systèmeDEMODiagrammes de flux DFD (dataflow diagram)05.juin.2012 54

1. Description du système05.juin.2012 55

1. Description du système Source de données (datastore)05.juin.2012 56

1. Description du système Processus/ programme (process)05.juin.2012 57

1. Description du système Acteur (actor)05.juin.2012 58

1. Description du système Flux (flow)05.juin.2012 59

1. Description du système Limite de confiance (trust boundary)05.juin.2012 60

1. Description du système DélimiteurIdentifier les actifs de haute valeur: de confiance (high-value assets) Est-ce que lon fait confiance aux administrateurs de cette zone? Est-ce que lon fait confiance aux autres hôtes de cette zone? Peut-on intercepter les communications dans cette zone? Etc.05.juin.2012 61

1. Description du systèmeIdentifier 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 sappliquent-elles? Les données sortiront-elles du système?05.juin.2012 63

1. Description du systèmeIdentifier 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 daccéder à dautres agents? Des agents de contrôle? Critique? Physique? Des autres organisations? (relais) Un système transactionnel interne? Est-ce grave si lagent sarrête?05.juin.2012 65

1. Description du systèmeIdentifier 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

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 dentrée dans notre système? (validation) Est-ce un vecteur dentrée chez un tiers? (encodage)05.juin.2012 69

1. Description du systèmeIdentifier les actifs de haute valeur: (high-value assets) On refait lexercice une seconde fois: il y a des choses que lon navait probablement pas compris au premier passage.05.juin.2012 71

1. Description du systèmeHVAs: Des mots de passe vont probablement transiter par les flux. Lapplication alimente le S.I. dune compagnie dassurance. Les données sont soumise à réglementation. Pas dinterception de trafic dans le cabinet. Mais on ne sait pas trop si les systèmes sont propres. Quid dun cheval de Troie?05.juin.2012 72

1. Description du systèmeHVAs: 2 flux entrants critiques --> Accroître la validation! 3 flux sortants critiques --> Veiller au traitement derreurs et messages 2 acteurs dont le client est à compromettre --> veiller à lencodage 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 contraintes05.juin.2012 73

1. Pourquoi utiliser le DFD?Réponse pragmatique: cest 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

2. Agents de menaceUtiliser une liste dagents formalisée La Direction est censée la connaître (1% des cas). La Direction en ignore lexistence (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

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 / étatique05.juin.2012 77

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 Loi05.juin.2012 78

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 + patient05.juin.2012 79

3. Quels scénarios?Rappel: Le modèle de menaces nest 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

3. Scenarios "doomsday"Un peu daide: (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 largent? Veut-il/elle porter atteinte à votre réputation? Veut-il/elle vous dénoncer aux autorités?05.juin.2012 82

3. Scenarios "doomsday"Un peu daide: (Evaluer pour chaque agent de menace) Veut-il/elle samuser avec des programmes de hack? Veut-il/elle accéder à votre système avec un client compromis? …à compléter05.juin.2012 83

3. Scenarios "doomsday"Décrire le scénario: Qui déclenche le scénario? (agent) Quelle est son intensité et lexposition du système? Quel serait limpact? Vol? Perte? Corruption? Perturbation? Financier? Légal? Réputation? Productivité? Santé? Comment le scénario se déroule-t-il? Décrire ce quil se passe quand on crie "Attaque!!" --> larbre dintrusion05.juin.2012 84

3. Scenarios "doomsday" Scénario ??? Scénario ??? Scénario … Scénario …05.juin.2012 85

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 dun autre Scénario Un cheval de Troie est injecté dans le réseau de la compagnie dassurances Scénario Le compte daccès du médecin est volé et discrètement surveillé par une agence de renseignement. Scénario … Scénario …05.juin.2012 86

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 lobtient. Réputation: impact moyen si cela se sait. Chemin La BDD est obtenue grâce à une injection de code: dintrusion - un paramètre na pas été validé correctement #1 - linjection déclenche une exécution de script côté BDD - les données sont retournées à lattaquant (soit en ligne directe, soit après écriture dans un fichier temp.)05.juin.2012 87

3. Scenarios "doomsday" Chemin La BDD est obtenue depuis lintérieur du réseau dintrusion dhébergement: #2 - Lattaquant sauthentifie dans le système. - Lattaquant copie les données sur un support externe ou les envoie à travers le réseau Chemin Lattaquant obtient laccès au compte du médecin: dintrusion -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 posteRepeat with the other scenarios… daccès05.juin.2012 88

3. Scenarios "doomsday" Attack trees Chemin La BDD est obtenue grâce à une injection de code: dintrusion #1 - un paramètre na pas été validé correctement - linjection déclenche une exécution de script côté BDD - les données sont retournées à lattaquant (soit en ligne directe à travers les messages derreur, soit après écriture dans un fichier temp.) Paramètre non-validé Injection de code Message Fichier temp derreur accessible lisible Vol de la BDD patients05.juin.2012 89

3. Scenarios "doomsday" Attack trees Chemin La BDD est obtenue depuis lintérieur du réseau dintrusion #2 dhébergement: - Lattaquant sauthentifie dans le système. - Lattaquant 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 patients05.juin.2012 90

3. Scenarios "doomsday" Attack trees Chemin Lattaquant obtient laccès au compte du médecin: dintrusion -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 daccè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 didentifiants locale Code Mdp obtenu Vol local Mdp volé injection Vol de la BDD patients05.juin.2012 91

3. Scenarios "doomsday" Arbre Simple dintrusion #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 patients05.juin.2012 92

Processus1. Décrire le système2. Identifier les agents de menace3. Identifier les scénarios de menace4. Identifier les contremesures5. Documenter/mettre à jour le modèle6. Diffuser le modèle05.juin.2012 93

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 stolen05.juin.2012 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 attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen05.juin.2012 95

4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points dentré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 stolen05.juin.2012 96

4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points dentré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 stolen05.juin.2012 97

4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points dentré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 stolen05.juin.2012 98

4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points dentrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle daccès physique email Bruteforce attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen05.juin.2012 99

4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points dentrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle daccès physique email Bruteforce - ??? attack Local intrusion Stolen credentials Bruteforced Vulnerable or Guessed parameter Local Code stealing Got cabinet injection password Patient database is stolen05.juin.2012 100

4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points dentrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle daccè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 stolen05.juin.2012 101

4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points dentrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle daccè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 stolen05.juin.2012 102

4. Identifier les contrôles Attack tree for Simple Network sniffing - Valider les données à tous #1 scenario password les points dentrée. Traffic Weak - Gestion des Malware à password interception mises jour Known local Physical - Hardening du système password intrusion Hacked - Contrôle daccè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 stolen05.juin.2012 103

4. Identifier les contrôles Attack tree for scenario #1- Valider les données à tous Traffic Weakles points dentrée. interception Malware password- Gestion des mises à jour Hacked- Hardening du système email Bruteforce- Contrôle daccès physique attack- Politique de mdp Stolencomplexe credentials Bruteforced or Guessed- Accès distant via protocolechiffré Got cabinet password Patient database is stolen05.juin.2012 104

4. Identifier les contrôles Attack tree for scenario #1- Valider les données à tous lespoints dentrée. Traffic Weak interception Malware password- Gestion des mises à jour- Hardening du système Hacked- Contrôle daccès physique email Bruteforce- Politique de mdp complexe attack- Accès distant via protocole chiffré- Politique de mdp complexe Stolen(webapp) credentials Bruteforced- Pas denvoi du mdp par email or Guessed- SSL/TLS- Authentification forte Got cabinet- Protection contre force brute password Patient database is stolen05.juin.2012 105

4. Identifier les contrôles Attack tree for scenario #1- Valider les données à tous lespoints dentrée. Traffic Weak interception Malware password- Gestion des mises à jour- Hardening du système Hacked- Contrôle daccès physique email Bruteforce- Politique de mdp complexe attack- Accès distant via protocole chiffré- Politique de mdp complexe Stolen(webapp) credentials Bruteforced- Pas denvoi du mdp par email or Guessed- SSL/TLS- Authentification forte Got cabinet- Protection contre force brute password Patient database is stolen05.juin.2012 106

4. Identifier les contrôles Vol de la BDD patients Contremesures - Valider les données dans les points dinjection arbre dattaque #1 Contremesures - Maintenir le système à jour et le renforcer arbre dattaque #2 - Protéger laccès physique au système - Politique de mdp locaux complexe - Accès distant via protocole chiffré Contremesures - Politique de mdp complexe arbre dattaque #3 - Pas denvoi du mdp par email, short lifetime recovery link - SSL/TLS - Authentification forte - Mécanisme anti-force brute05.juin.2012 107

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 dun autre Scénario Un cheval de Troie est injecté dans le réseau de la compagnie dassurances Scénario Le compte daccès du médecin est volé et discrètement surveillé par une agence de renseignement. Scénario … Scénario …05.juin.2012 108

5. Documenter/mettre à jour le modèle de menaceProposition: 1. Contexte 2. Description du système 1. Diagramme(s) DFD 2. Actifs de haute valeur 3. Agents de menace 4. Scénarios dintrusion 5. Liste des contremesures 6. Plan daction05.juin.2012 110

6. Diffuser le modèle ?????En général, un document infosécurité sadresse à des professionnels de linfosécurité.Même si lon 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énario05.juin.2012 112

6. Diffuser le modèlePour accroître ladoption de la méthode: Le plan daction doit être acceptable. Votre vision est probablement fausse, consultez le client!Ne pas en faire trop: garder une vision globale du risque à lesprit!Lobjectif est daméliorer avec les moyens du bord, pas de dénoncer les manquements!05.juin.2012 113

6. Diffuser le modèle en interneQuels destinataires? Les architectes: certaines recommandations les guideront dans la conception de lapplication. 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

6. Diffuser le modèle à léditeurLe modèle de menace formalise la préoccupation du client et ses enjeux stratégiques.Il peut être inclus dans le critère dacceptation des livrables à différentes étapes: • Spécification fonctionnelle de lapplication • Contrainte de conformité: "lapplication ne doit pas être vulnérable aux attaques suivantes" • Contrainte pour le plan dassurance qualité: "le plan de test doit évaluer la résistance aux attaques décrites dans le MdM" • Etc.05.juin.2012 115

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 loutil STRIDE sur chaque composant de larchitecture.05.juin.2012 117

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 dexploitation? Application web + serveur web + système dexploitation + hardware? Etc.Essayer lapproche systématique: Application exhaustive du modèle STRIDE + Outil TAM toolAjuster le positionnement de lorganisation: Niveau 1: Conformité Niveau 2: Défense what we did Niveau 3: Défense et détection Niveau 4: Défense, détection, contremesure05.juin.2012 118

Aller plus loin… Points dinjection serveur05.juin.2012 119

Aller plus loin… Points dinjection client05.juin.2012 120

Aller plus loin… Points de fuite05.juin.2012 121

Aller plus loin… Configuration cryptographique05.juin.2012 122

Aller plus loin… Menaces technologiques05.juin.2012 123

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 dintrusion05.juin.2012 124

Aller plus loin…STRIDE threat identification tool http://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspxDREAD severity assessment tool http://en.wikipedia.org/wiki/DREAD:_Risk_assessment_modelOWASP threat risk modeling https://www.owasp.org/index.php/Threat_Risk_ModelingMicrosoft SDL design phase activities + TAM tool http://www.microsoft.com/security/sdl/discover/design.aspx05.juin.2012 125

ConclusionLe 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 aujourdhui bien identifiées.05.juin.2012 126

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 lapplication. Le client na pas nécessairement besoin de le comprendre. En revanche, lexpert sécurité doit avoir compris le besoin du client…05.juin.2012 127

ConclusionLe modèle de menaces risque de nous éloigner des préoccupations principales. Garder un œil sur la vue densemble: de quoi veut-on se protéger et pourquoi? Rester simple, et modeste.05.juin.2012 128

Suivez lOWASP près de chez vous (et cest 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-geneva05.juin.2012 129

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/starbuck300005.juin.2012 130

Modéliser les menaces d'une application web

by Antonio Fontes on Jun 06, 2012

Accessibility

Categories

Upload Details

Usage Rights

Statistics

Modéliser les menaces d’une application web Presentation Transcript