Symposium sur le privacy by design présenté par Alexandre Perrin

1. LE PRIVACY BY DESIGN

2. À propos

3. 3
▶ Découle d’un rapport de 1995 sur
les Privacy-enhancing
technologies
▶ Écrit par la Commissaire à
l’Information et la Vie Privée de
l’Ontario l’Autorité de Protection
des Données Néerlandaise et
l’Organisation Néerlandaise pour
la Recherche Scientifique
Appliquée
▶ Repris dans un avis par le
contrôleur européen de la
protection des données (CEPD)
Le 22 mars 2010
Histoire du privacy by design

4. 4
▶ Prendre des mesures proactives et non réactives
La prise en compte de la vie privée dès la conception consiste à prévoir et à prévenir
les incidents d’atteinte à la vie privée avant qu’ils ne se produisent.
▶ Assurer la protection implicite de la vie privée
Il s’agit de veiller à ce que les données à caractère personnel soient protégées de
façon automatique. Ainsi, les nouvelles technologies doivent être paramétrées « par
défaut » de façon à assurer un niveau de protection des données personnelles
maximum. L’utilisateur lui-même n’a pas à définir lui-même les conditions
d’utilisation de ses données.
▶ Assurer une fonctionnalité intégrale selon un paradigme à somme
positive et non à somme nulle
La prise en compte de la vie privée ne doit pas empêcher la mise en oeuvre d’autres
fonctionnalités. Il est possible de réaliser deux plusieurs objectifs à la fois sans les
compromettre.
Les 7 grands principes

5. 5
▶ Intégrer la protection de la vie privée dans la conception des systèmes et
des pratiques
La protection de la vie privée est intégrée dans la conception et l’architecture
des systèmes informatiques et des pratiques des organismes; elle n’y est pas
greffée a posteriori. La protection de la vie privée devient donc un élément
essentiel des fonctionnalités de base. Elle fait partie intégrante du système,
sans porter atteinte à ses fonctions.
▶ Assurer la sécurité de bout en bout, pendant toute la période de
conservation des renseignements
Des mesures de sécurité essentielles à la protection de la vie privée sont mises
en oeuvre du début jusqu’à la fin. Cela permet d’assurer la conservation
sécurisée des données, puis leur destruction sécurisée à la fin de leur période
de conservation. Ainsi, la protection intégrée de la vie privée assure une
gestion intégrale, sécurisée et de bout en bout des renseignements pendant
toute leur période de conservation.
Les 7 grands principes

6. 6
▶ Assurer la visibilité et la transparence
Les éléments et le fonctionnement du système demeurent visibles et
transparents, tant pour les utilisateurs que pour les fournisseurs. La vérification
permet d’établir un climat de confiance.
▶ Respecter la vie privée des utilisateurs
Il s’agit d’offrir aux clients la garantie d’un traitement des données qui soit à la
fois parfaitement sûr et qui corresponde exactement à leur besoin, sans
collecter plus de données que nécessaire.
Les 7 grands principes

7. 7
Quelques
principes de
sécurité

8. 8
▶ Prendre en compte de la sécurité dès la conception
● Cahier des charges des exigences de sécurité
▶ Évaluer la sécurité sur 4 critères
● Disponibilité
● Intégrité
● Confidentialité
● Traçabilité
▶ Gérer la sécurité par une appréciation des risques
● ISO 27005, Méthodes EBIOS, MEHARI, ...
▶ Appliquer les principes de défense en profondeur
● Plusieurs niveaux de protection mis en oeuvre dès la conception
● Chaque dispositif doit être considéré comme potentiellement vulnérable et doit
être à minima doublé par un autre dispositif indépendant
▶ Former et sensibiliser les utilisateurs / développeurs
▶ Assurer le maintien en conditions de sécurité
Principes fondamentaux de sécurité

9. Et pourtant...
9

10. Et pourtant...
10Source : 2017 Verizon Data Breaches Investigations Report

11. Dans la pratique...
11Source : The State of Risk-Based Security Management, Ponemon Institute - IBM

12. Quelques conséquences
12
▶ Utilisation de composants vulnérables
● The Mossack Fonesca (Panama Papers) breach, which was caused by a vulnerability in an old, unpatched version of Drupal.
● The VericalScope/Techsupportforum.com breach in which 45 million passwords and IP addresses were stolen from a network of over
1,100 websites and forums. The cause was said to be a known vulnerability in an old version of the vBulletin forum software.
● The Ubuntu forums breach in which 2 million usernames, IP addresses and passwords were compromised from the official Ubuntu
forums. The cause was a SQL injection vulnerability in the Forumrunner add-on which had not been patched”.
▶ Erreurs de configuration
● The Mexican Voters Breach in which registration data of 93.4 million voters was publicly exposed, although probably not offered for sale
on the dark net. The compromised database turned out to be a legitimate copy of the registration data belonging to a political party, who
had uploaded it to AWS without securing it.
● The US Voters / Amazon / Google breach in which 154 million profiles of US voters with rich personal details was taken by a Serbian
hacker. The data was stored in a CouchDB database which required no authentication, stored on Google Cloud Services.

13. Quelques conséquences
13
▶ Injections
● The Philippines’ Commission on Elections breach, in which 77,736,795 records, representing the entire adult population of the
Philippines (!) were stored in plaintext and easily obtained by a hacker via SQL injection.
● The i-Dressup breach, in which 5.5 million accounts of teenage girls, including passwords stored in plaintext, were compromised by an
SQL injection which exploited an unknown vulnerability on the website.
● The Michigan State University breach, in which 400,000 names and email addresses were obtained by a 17-year-old hacker from the
Netherlands who scanned the web for SQL injection vulnerabilities. Fortunately, passwords were encrypted in this case.
▶ Problèmes d’authentification ou d’habilitations
● A2 was the cause for the 17 Media Breach (30 million accounts breached for a streaming app), the Aerticket breach (data for 1.5 million
German airline passengers breached), and the Kroger/Equifax breach (tax and salary data for 431,000 people who filled tax forms
online).
● A6 was the cause for the Kerala beach (personal details breached for 34 million residents of the State of Kerala in India), the Indian
Institute of Management breach (test scores of 2 million participants in the CAT psychometric exam were exposed on the Internet), and
the BlueSnap/Regpack breach (324,000 payment records lost including CVV codes, allowing attackers to bypass credit card security).

14. Quelques conséquences
14
▶ D’après une étude réalisée par Google entre mars 2016 et mars 2017,
● 788 000 identifiants Google auraient été volés par des
keyloggers,
● 12 millions par des opérations de phishing et
● 3,3 milliards au travers d’applications tierces.
▶ Soit 250 000 par semaine

15. Pourquoi ?
▶ Manque de maturité dans le domaine
▶ La valeur ajoutée par la sécurité est difficile à démontrer
▶ La sécurité est mal intégrée aux projets
● Pas perçue comme un besoin d’affaire
● Perçue comme une couche de peinture qu’on applique au produit final
● on entend souvent: « L’important est que l’application fonctionne. Ensuite
on verra pour la sécurité »
● remplaçons « l’application » par « l’avion » et voyons si c’est aussi bien
accepté
▶ Perçue comme cause de dépassements de coût et de
planning
15

16. 16
Pourquoi
sécuriser les
développements ?

17. Conformité réglementaire et
juridique
▶ RGPD
▶ LPM, NIS
▶ PCI-DSS
▶ Réglementations spécifiques au métier
▶ ...
17

18. Coûts
18

19. Couts
19Source : Ponemon Institute’s 2017 Cost of Data Breach Study - France

20. 20
Solutions

21. ISO 27034
▶ Modèle pour faciliter l’intégration de la sécurité dans le cycle
de vie des applications
● Concepts, principes
● Composants et processus
▶ Elle s’applique autant au développement interne qu’à
l’acquisition
▶ Elle ne propose pas de règles de développement
21

22. ISO 27034 - principes
22

23. ISO 27034 - principes

24. ISO 27034 - périmètre
24
Personnes
Processus
Informations
Logiciels
Infrastructure
▶ Portée de la sécurité d’une application

25. ISO 27034
25

26. ISO 27034
26
Bonne pratiques et mesures
de sécurité de l’entreprise Processus de l’entreprise
relatifs à la sécurité
modèle standard de cycle de vie sécurisé d’une application

27. Microsoft SDL
27

28. Microsoft SDL
▶ Compatible ISO 27034
28

29. Threat modeling
▶ Identification des assets
● Il faut savoir quoi protéger
■ Propriété intellectuelle
■ Données personnelles
■ Données financières
■ Réputation de l’entreprise
■ Serveur
■ ...
29

30. Threat modeling
▶ Data flow
● Permet de déterminer les vecteurs de menace et la surface d’attaque
30

31. Threat modeling
▶ Détermination des menaces
31

32. Threat modeling
▶ Détermination des menaces
● MITRE
32

33. Threat modeling
▶ CWE-89
● Improper Neutralization of Special Elements used in an SQL Command ('SQL Injection')
▶ CWE-78
● Improper Neutralization of Special Elements used in an OS Command ('OS Command Injection')
▶ CWE-79
● Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')
▶ CWE-434
● Unrestricted Upload of File with Dangerous Type
▶ CWE-352
● Cross-Site Request Forgery (CSRF)
▶ CWE-601
● URL Redirection to Untrusted Site ('Open Redirect')
33

34. Threat modeling
▶ SANS TOP 25
34

35. Threat modeling
▶ Détermination des menaces :
● OWASP Top 10
35

36. Threat modeling
▶ Cotation des risques
36

37. Threat modeling
▶ Classement des risques
▶ Le PO décide des risques à traiter
37

38. Problèmes avec SCRUM
▶ On ne peut pas tout réaliser dans chaque Sprint
▶ L’architecture, les User Stories et le design évoluent dans le temps
▶ La sensibilité des données, les sources de menaces et les protections à
mettre en oeuvre ne sont pas toujours connues à l’avance
▶ Les équipes SCRUM disposent rarement des ressources nécessaires
(expert sécurité, Threat modeler, ...)
38

39. Problèmes avec SCRUM
39

40. 40
Et en SCRUM, on
fait comment ?

41. Sprint 0
▶ Formation de l’équipe
▶ Détermination des contraintes externes/internes
● Contexte légal
● Contexte réglementaire
● Contexte technique
● PSSI
● ...
▶ Analyse des besoins en sécurité sur les EPICS
● Détermine le niveau de criticité de l’application
41Source ANSSI

42. Sprint 0
▶ Première analyse de risques
42
Source ANSSI

43. Sprint 0
▶ Création du profil de sécurité de l’application
▶ Ajout de “security stories” dans le backlog produit
43

44. Sprint 0
▶ Safecode Agile Dev Security - Security story
44

45. Sprint planning
▶ Etude de risque sur les User Stories
▶ Un risque se matérialise par une “evil story”
● «en tant qu’utilisateur, je réserve en ligne mon billet de spectacle».
● «En tant qu’hacktiviste,j’empêche les clients de réserver en ligne leur billet de
spectacle en saturant le serveur applicatif par une attaque en déni de service.
Ceci conduit à un impact préjudiciable sur l’image et la crédibilité du gestionnaire
du service, voire une perte de clients»
▶ Le PO détermine comment traiter le risque : accepté, éviter, réduire,
partager
▶ Chaque mesure pour réduire le risque se traduit par une tâche dans le
backlog de sprint
45

46. Sprint planning
46
developper
“As a
developper, I
want to verify
every input

47. Sprint
▶ Vérification statique
● Audit de code et de configuration automatique
● Sonar
● Checkstyle
● …
● Audit de code manuel
47
CVE-2005-0455 dans RealPlayer - passe les vérifications statiques

48. Fin de Sprint ou Release
▶ Analyse dynamique
● OWASP ZAP
● Plugin Jenkins
48

49. Fin de Sprint ou Release
▶ RATS
49

50. Release ou fin de projet
▶ Envisager un pentest selon la criticité de l’application
50

51. Itération de sécurité
▶ Pas recommandé mais parfois nécessaire
51

52. Questions
52

53. The end
53