Cloud, DevOps, CI/CD, Microservices... Ces paradigmes à la mode engendrent leur lot d’enjeux de sécurité. Mieux vaut connaitre ces derniers à l’avance que de les découvrir trop tard dans le parcours. Nous avons discuté des divers aspects de sécurité que vous aurez à considérer lors de l’adoption de ces paradigmes

1. The OWASP Foundation
http://www.owasp.org
Buzzwords
et enjeux de sécurité
Patrick Leclerc
Louis Nadeau

2. OWASP World
L’OWASP (www.owasp.org) est
une organisation mondiale à but
non-lucratif (501c3)
Elle a pour mission de rendre la
sécurité applicative visible afin de
permettre au gens et organisations de
prendre des décisions informées
sur les vrais risques de sécurité
des applications.
Tout le matériel OWASP est
disponible gratuitement sous
licence « open software ».
OWASP demeure neutre et
indépendante des fournisseurs de
produits et de services
2

3. Patrick Leclerc
• Conseiller en sécurité informatique à La Capitale
• Leader du chapitre OWASP Québec
• 24 ans d’expérience en développement:
 Développement
 Architecture logicielle
 Architecture de solutions / systèmes
 Sécurité applicative
3

4. Louis Nadeau
• Directeur AppSec chez Bentley System
• Vice-leader du chapitre OWASP Québec
4

5. Mise en garde
Cette présentation ne vas pas tenter de vous
expliquer les technologies, méthodologies,
processus, patterns ou idéologies des
« Buzzwords » couverts
Elle traitera plutôt des enjeux de sécurité qui
découlent de leur usages
5

6. Sujets / Buzzwords abordés
• Responsabilités dans le Cloud
• Risques de sécurité du Cloud OWASP Cloud Top 10
• Sécurité applicative dans le Cloud
• « DevOps »: Enjeux et recommandations
• « CI/CD »: Enjeux et recommandations
• « Microservices » : Enjeux et recommandations
• Top 10 pour sécuriser vos microservices
6

7. Mise en contexte du
Cloud Computing
7

8. Réseau
Stockage
Hyperviseur
Machine virtuelle
Application
Données
Réseau
Stockage
Hyperviseur
Machine virtuelle
Application
Données
Réseau
Stockage
Hyperviseur
Machine virtuelle
Application
Données
IaaS PaaS SaaS
Ligne des responsabilités La sécurité est de votre responsabilité
Les responsabilités de sécurité dans le Cloud
8

9. Top 10 OWASP des risques du Cloud (2014)
9https://www.owasp.org/index.php/Category:OWASP_Cloud_%E2%80%90_10_Project

10. Sécurité applicative et
Cloud Computing
10

11. Risques de sécurité applicative dans le Cloud
• D’un point de vue applicatif, le Cloud n’est qu’une nouvelle façon de
déployer les ressources informatiques.
• Contrairement à certaines perceptions, le Cloud n’opère aucune magie
quant à la sécurité des applications:
• Si la sécurité d’une application n’est pas déjà assurée à l’intérieur de
votre organisation, elle ne pourra l’être davantage sur le Cloud.
11

12. Risques de sécurité applicative dans le Cloud
• Dans le Cloud vous devrez prendre en compte l’augmentation de
l’exposition de votre application, ou plutôt l’augmentation de la
probabilité d’une attaque.
• Si vous migrez sur le Cloud une application autrefois conçu pour un usage
interne, vous aurez certainement à composer avec une augmentation de
la probabilité d’usages abusifs.
• Il est encore plus important dans un développement de solutions
Cloud d’anticiper les menaces tôt dans le cycle de développement
qu’il ne l’est pour un développement traditionnel.
12

13. Où dépensez vous?
13

14. Top 10 (2013) des risques applicatifs
14https://www.owasp.org/index.php/Top_10_2013-Top_10

15. Top 10 (2017) des risques applicatifs
15https://www.owasp.org/index.php/Top_10-2017_Top_10
Bleu clair (nouveau)
Violet (merge)
Orange (élevé)
Vert (abaissé)

16. 16

17. « DevOps » c’est quoi?
17

18. 18

19. Le DevOps représente un changement dans la culture informatique,
en mettant l'accent sur la prestation de services informatiques
rapides grâce à l'adoption de pratiques agiles et allégées dans
le contexte d'une approche orientée système.
Le DevOps met l'accent sur les personnes (et la culture) et cherche à
améliorer la collaboration entre les opérations et les équipes
de développement.
Les implémentations DevOps utilisent la technologie - en particulier
les outils d'automatisation qui peuvent tirer parti d'une
infrastructure de plus en plus programmable et dynamique
dans une perspective de cycle de vie.
19
« DevOps » selon Gartner
https://www.gartner.com/it-glossary/devops

20. But du « DevOps »
 Augmenter la vitesse de livraison
 Augmenter la collaboration entre Dev et Ops
 Livrer plus fréquemment de petites fonctionnalités
 Diminuer les dépenses des opérations
 Automatiser la livraison et le déploiement logiciel
 Focus sur l’application plutôt que l’infrastructure
 Support multiplateformes et multi langages
20

21. Défis de sécurité du DevOps
Plus de livraisons, et plus rapidement…
 Pression sur les équipes de
sécurité
? Comment les équipes de sécurité
pourront suivre le rythme des
livraisons rapides?
? Comment peut-on s’assurer de
livrer des applications sécuritaires?
21

22. SecDevOps ou DevSecOps?
Pour ne pas trop ralentir la vitesse de livraison…
• Augmenter la collaboration entre Sec, Dev et Ops
• Former et responsabiliser les Devs des risques des
applications qu’ils développent, les Sec sont en support
• Intégrer la sécurité plus tôt dans le cycle de
développement « shift left »
• Identifier et incorporer les « requis » et « stories »
de sécurité
22

23. Why “Shift-Left” ?
VS
Security “Baked in” Security“ Bolted on”

24. SecDevOps (suite)
Pour diminuer les dépenses des opérations…
• Intégrer des tests de sécurité le plus tôt
possible dans le cycle de Dev
• Automatiser les tests de sécurité (SAST, DAST, IAST)
• Accélérer la rétroaction des tests vers les Dev
24

25. Vérifications de sécurité
Analyse des menaces (plan)
• Identifier les risques et les requis de sécurité
Revue de conception (plan)
• Vérifier si les requis de sécurité sont traités
• Identifier les lacunes dès la conception
Analyses statiques automatisées (code, build)
• Outils d’analyse des vulnérabilités identifiables dans le code (SAST)
Analyses dynamiques (test)
• Outils d’analyse des vulnérabilités identifiables au « Run-time » (DAST)
Revue de code manuelle des portions stratégiques (test)
• Vérifier les fonctions de sécurité et communes
25

26. CI/CD & CD
Intégration continue (Continuous Integration )
• L'intégration continue se concentre sur l’intégration des sources des différents développeurs dans
un dépôt commun. Le « commit » des modifications déclenche une automatisation de la
compilation, et de l’exécution de tests unitaires, de tests de qualité et de sécurité du code.
L’objectif est de permettre une détection précoce des bogues et vulnérabilités.
Livraison continue (Continuous Delivery)
• La livraison continue consiste à minimiser les points de friction du processus de déploiement. La mise
en œuvre implique l'automatisation des étapes de préparation, déploiement et de tests afin de
livrer une version éprouvée en pré production. Une validation humaine finale est réalisée
avant le déploiement en production.
Déploiement continue (Continuous Deployment )
• Le déploiement continu est similaire à la livraison continue sauf que le déploiement s’automatise sans
validation en amont.
• Le système est capable de faire un retour arrière automatique en cas d’erreurs bloquantes
26https://www.atlassian.com/continuous-delivery/ci-vs-ci-vs-cd

27. Enjeux CI/CD
Tests automatisés (en CI/CD)
 Est-ce qu’un contrôle en amont assure qu’un développeur ne puisse pousser du
code dans le dépôt sans approbations? (Ex: « Pull request »)
 Avez-vous tenu compte de la séparation des tâches dans vos processus?
 Est-ce que des revues de code manuelles font partie de votre processus? Il y
a des failles que seul l’humain peut encore trouver! (ex: failles de logique
applicative)
 Est-ce que les requis de sécurité on été identifiés? Font-ils partie des cas de tests
que vous avez automatisés?
 Quelle est la nature et la complétude des tests au niveau de la sécurité?
 Est-ce qu’un seuil minimum de sécurité est enforcé avant de poursuivre?
27

28. 28
Déploiement continu (CD)
 Est-ce que des vérifications assurent les configurations sécuritaires sont
appliquées aux images à déployer?
 Est-ce que des vérifications assurent la légitimité des images à graduer en
production? (Ex: vérification de la source et/ou signature de l’image)
 Est-ce que des mécanismes de détection et de protection sont déployés en
production pour identifier et répondre aux abus?
 Avez-vous un plan de gestion et de réponse aux incidents efficace?
Enjeux de déploiement

29. Microservices c’est
quoi?
29

30. Microservices selon Martin Fowler
https://martinfowler.com/articles/microservices.html

31. Architecture de microservices
Selon Martin Fowler:
Approche permettant de développer une seule application en tant
qu’assemblage de petits services, chacun s'exécutant dans son
propre processus et communiquant avec des mécanismes légers,
souvent via une API de ressources HTTP.
Ces services sont construits autour de capacités métier et
déployables indépendamment et de façon entièrement
automatisées.
Il existe un minimum de gestion centralisée de ces services, qui
peuvent être écrits dans différents langages de programmation
et utiliser différentes technologies de stockage de données.
Source: https://martinfowler.com/articles/microservices.html
https://martinfowler.com/articles/microservices.html 31

32. Microservices: caractérisques
9 caractérisques (selon Fowler):
1) Fragmentation en services
2) Focus sur les capacités affaires
3) Livraison de produits et non de projets
4) Intelligence dans les services (Smart endpoints and dumb pipes)
5) Gouvernance décentralisée (plus facile de mette à jour les services)
6) Gestion des données décentralisée
7) Automatisation de l’infrastructure
8) Conception tolérante aux défaillances
9) Conception évolutive
32

33. Microservices: caractérisques et enjeux
• Données décentralisées
 Complexité à gérer la sécurité des sources de données sensibles distribuées
• Plusieurs langages et technologies différentes
 Addition potentielle des vulnérabilités de chaque technologie
• Architecture fragmentée et distribuée
 Difficulté à avoir une vision complète et cohérente des risques
 Complexité à définir et contrôler tous les flux de communications
• Gouvernance décentralisée
 Décentralisation des autorisation et validations de sécurité vers les services
 Surveillance et corrélations plus complexes à effectuer
• Fréquence et multiplicité de livraisons indépendantes
 Tests plus complexes à réaliser (moins de cohérence, moins de complétude)
33

34. Tout d’abord…
 Ne vous embarquez pas dans le hype des microservices à
moins d’avoir dûment compris, considéré et pesé les avantages
et les désavantages de ce pattern!
Gartner mentionne:
• Les microservices sont devenus une aspiration plutôt qu'un choix rationnel
• La complexité est déplacée et étendue, non supprimée
• La maturité des technologies de microservices est encore très variable
• La modernisation de l'infrastructure des applications est nécessaire
• Un changement de culture est requis
Si vous y allez:
 Maitriser ce que vous faites, on peut perdre le contrôle plus
facilement qu’avec les apps monolithiques!
34You Are Not Netflix: How and When to Use Microservices in the Enterprise: https://www.gartner.com/webinar/3437517

35. Recommandations de sécurité
• Intégrer très tôt (dès l’architecture) la sécurité dans les microservices
• Déterminer quels services pourront consommer les données et en
limiter la portée (ex: utilisez le pattern CQRS)
• Prévoir et contrôler les scénarios de messaging entre les services
(identifier les pub sub de confiance)
• Appliquer l’authentification, l’autorisation et les vérifications à tous les
services
• Sécuriser les secrets (pas d’identifiants et de mots de passe en clair
dans dans le code, fichiers docker ou variables d’environnement)
35AppSec EU 2017 Security In The Land Of Microservices by Jack Mannino https://www.youtube.com/watch?v=JRmWlLY8MGE

36. 36
Top 10 pour sécuriser
vos microservices

37. Top 10(+): Sécuriser les microservices
1. Utilisez la plus récente version de TLS (encryptez TOUT trafic vers les
microservices)
2. Authentifiez les processus consommateurs ou utilisateurs finaux de
vos API (respecter les bonnes pratiques d’authentification et de gestion des
sessions)
3. Autorisez à CHAQUE COUCHE les processus consommateurs ou utilisateurs
finaux en respectant les principes du moindre privilège nécessaire et le celui
du besoin de connaitre (contrôle d’accès à chaque composant)
4. Protégez vos API des DDoS en utilisant les mécaniques de contrôles tels que
: Rate Limiting, Throttling, Daily limits, etc.
5. Concevez une infrastructure sécuritaire en appliquant le principe de
défense en profondeur, que ce soit sur site ou dans le Cloud (API
gateway, IDS, WAF, RASP, cloisonnement réseau)
“Top 10 things to protect your Microservices”, AppSecUSA 2017, Chintan Jain, Capital One 37

38. Top 10(+): Sécuriser les microservices
6. Surveillez vos API pour détecter et alerter lors de l’observation de
patterns anormaux et d’évènements de sécurité
7. Rendez vos API résilients à la perte de disponibilité des microservices
(résilience des centres de données, régions, microservices et toutes les
dépendances, etc.)
8. Protégez les secrets (clés privées, mots de passe systèmes, etc.) L’exposition
de l’un d’entre eux peut annihiler les autres contrôles de sécurité
9. Chiffrez les données sensibles (au repos et en transit) avec les
algorithmes et l’entropie appropriés (encryption/hashing)
10. Durcissez les configurations de vos systèmes et programmez sécuritaire
“Top 10 things to protect your Microservices”, AppSecUSA 2017, Chintan Jain, Capital One 38

39. 24 avril: conférence OWASP Québec
La sécurité dans un
environnement
docker/kubernetes/cloud avec
micro-services
(par Vincent Crépin)
https://www.owasp.org/index.php/Quebec_City 39

40. Références
https://www.owasp.org/index.php/Category:OWASP_Cloud_%E2%80%90_10_Project
https://www.owasp.org/index.php/Top_10_2013-Top_10
https://www.owasp.org/index.php/Top_10-2017_Top_10
https://www.gartner.com/it-glossary/devops
https://www.atlassian.com/continuous-delivery/ci-vs-ci-vs-cd
http://blog.myagilepartner.fr/index.php/2017/01/05/quest-ce-que-le-continuous-delivery-et-continuous-
deployment/
Notorious Nine (TOP 9 des menaces) https://cloudsecurityalliance.org/research/top-threats
NIST SP800-145 : http://csrc.nist.gov/publications/nistpubs/800-145/SP800-145.pdf
https://cloudsecurityalliance.org
https://automic.com/blog/whats-the-difference-between-devops-and-continuous-delivery
https://dzone.com/articles/what-is-cicd
AppSec EU 2017 Security In The Land Of Microservices by Jack Mannino
(https://www.youtube.com/watch?v=JRmWlLY8MGE)
“Top 10 things to protect your Microservices”, AppSecUSA 2017, Chintan Jain, Capital One
(https://www.youtube.com/watch?v=VtUQINsYXDM)
40

41. Plusieurs ressources OWASP...
• OWASP Top 10 (2017) des risques de sécurité applicatives
• OWASP podcasts, vidéos, webinars, présentations, livres…
• OWASP SAMM (Software Assurance Maturity Model)
• OWASP Secure Coding Practices
• OWASP ASVS (Application Security Verification Standard)
• OWASP Webgoat et BWA (Broken Web Application)
• OWASP Cheat sheets
• OWASP Code Review Guide
• OWASP Testing Guide
• OWASP Zed Attack Proxy (ZAP)
41

42. Impliquez vous! Supportez-nous!
Bénéfices des membres OWASP: $50/an
• Rabais sur les conférences
• Une adresse de courriel: toi@owasp.org
• Droit de vote dans les élections
• Reconnaissance sur le site de l’OWASP
• 40% du montant versé au chapitre ou à un projet
• Pour nous commanditer, suivre le lien « donate » sur
https://www.owasp.org/index.php/Quebec_City
42

43. Supportez OWASP!
Devenir membre pour un don annuel de:
• Individuel $50
• Corporatif $5000
Permet à OWASP de supporter les initiatives:
projets, listes de distribution, conférences, podcasts, bourses et
coordination des activités mondiales…
43

44. Merci!
OWASP Ville de Québec
https://www.owasp.org/index.php/Quebec_City
patrick.leclerc@owasp.org
louis.nadeau@owasp.org
44