Etude de cas - Modélisation des menaces d'une application web Forum PHP - 2012 Cité Universitaire, Paris

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. Quelques questions…
2

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. 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. 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. 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. 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. 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. 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. 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. Agenda
Contexte & motivations
Un peu de théorie
Etude de cas
Conclusions & perspectives
05.juin.2012 11

12. Agenda
Contexte & motivations
Un peu de théorie
Etude de cas
Conclusions & perspectives
05.juin.2012 12

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. 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. 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. Agenda
Contexte & motivations
Un peu de théorie
Etude de cas
Conclusions & perspectives
05.juin.2012 16

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. Exemples:
Liquidités
Machines de production, outils
Connaissances, données
Systèmes
Méthodes
Savoir-faire
Etc.
05.juin.2012 18

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. 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. « 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. 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. 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. « 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. 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. Exemples
Impacts spécifiques:
Mise en danger d'autrui
Responsabilité sociale
Non-conformité
Destruction matérielle
…
05.juin.2012 26

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. « 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. 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. “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. “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. 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. 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. 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. 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. « 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. 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. Agenda
Contexte & motivations
Un peu de théorie
Etude de cas
Conclusions & perspectives
05.juin.2012 38

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. 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. PLCM: le concept
Cas d'utilisation:
Assurances:
Rapport statistique mensuel et
anonymisé
05.juin.2012 41

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. PLCM: le client
Le pédiatre contacte une
agence web
Pouvez-vous
me faire ce
site?
Challenge
accepted!
05.juin.2012 43

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 1. Description du système
DEMO
Diagrammes de flux DFD (dataflow diagram)
05.juin.2012 54

55. 1. Description du système
05.juin.2012 55

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

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

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

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

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

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. 1. Description du système
05.juin.2012 62

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. 1. Description du système
05.juin.2012 64

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. 1. Description du système
05.juin.2012 66

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. 1. Description du système
05.juin.2012 68

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. 1. Description du système
05.juin.2012 70

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 3. Scenarios "doomsday"
Scénario ???
Scénario ???
Scénario …
Scénario …
05.juin.2012 85

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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Agenda
Contexte & motivations
Un peu de théorie
Etude de cas
Conclusions & perspectives
05.juin.2012 116

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. 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. Aller plus loin…
Points d'injection
serveur
05.juin.2012 119

120. Aller plus loin…
Points d'injection
client
05.juin.2012 120

121. Aller plus loin…
Points de fuite
05.juin.2012 121

122. Aller plus loin…
Configuration
cryptographique
05.juin.2012 122

123. Aller plus loin…
Menaces
technologiques
05.juin.2012 123

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