Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

OWASP Quebec - Histoire vraie : Implémenter le SecDevOps en entreprise

130 views

Published on

Lorsque l’on parle de DevOps, on parle aussi de l’importance d’avoir du SecDevOps, l’intégration de la sécurité dans le processus DevOps. Plusieurs sources, tel que le SANS, offrent des lignes directrices sur ce que devrait avoir un bon SecDevOps.

La théorie c’est bien, mais qu’en est-il en pratique? Quelle est la réalité lorsque l’on s’assis derrière son bureau et que l’on se dit « Commençons à implémenter notre SecDevOps »?

Lors de cette présentation, nous parlerons de la transformation interne de Bentley Systems vers le DevOps et par conséquent, l’implémentation du SecDevOps. Nous traverserons ensemble une année de travail à travers une personne qui a fait part de ce changement. Nous aborderons le début cahoteux, les bons et les moins bons coups, les défis rencontrés, etc.

Le but de cette présentation n’est pas d’expliquer ce qu’est un bon SecDevOps et comment l’implémenter. Il s’agit d’un témoignage d’une équipe de sécurité applicative qui a vécue et participée à son implémentation dans une entreprise de 30 ans d’âge.

Par:
Guillaume Croteau
Ingénieur Logiciel
Bentley Systems

Published in: Software
  • Be the first to comment

  • Be the first to like this

OWASP Quebec - Histoire vraie : Implémenter le SecDevOps en entreprise

  1. 1. Histoire vraie : Implémenter le SecDevOps en entreprise
  2. 2. Votre Narrateur • Guillaume Croteau – Application Security Engineer II, Bentley Systems – Génie Logiciel @ uLaval – GIAC-GWEB – (a essayé) OSCP
  3. 3. Chapitre 0: Prélude • Critères de sécurité chez Bentley Systems – Obligatoires – Optionnels • Vérification manuelle des sign-off de sécurité – Couverture minimale • Bentley Systems a 300 produits actifs – Erreur humaine possible (je le sais, je le fait)
  4. 4. Chapitre 0: Prélude
  5. 5. Chapitre 0: Prélude
  6. 6. Chapitre 1: Premiers (faux) pas • On veut automatiser la vérification manuelle des critères de sécurité pour les releases • On donne la tâche à des stagières/onboarders • On ne définit pas de backlog ni de plan précis • Pas de supervision ni de mentor
  7. 7. Chapitre 1: Premiers (faux) pas • Après > 2 mois, toujours rien d’automatisé • «Ça va marcher la semaine prochaine» (à chaque semaine) • On demande des résultats, mais rien n’est livré • À qui la faute?
  8. 8. Chapitre 2: L’ultimatum • DevOps sera fonctionnel chez Bentley Systems dans 5 mois • On a une date de livraison • Arrivé du Scorecard, nos critères de sécurité doivent y être intégrés • Tous les critères de sécurité obligatoires doivent être automatisé d’ici cette date • On a une plateforme à supporter (Azure DevOps, p.k.a. VSTS)
  9. 9. Chapitre 2: L’ultimatum • Comprendre ce qu’il y a à faire: – Scorecard = gardien des releases automatisés • En d’autre termes, vérification des critères (de sécurité) – Certaines tâches de sécurité peuvent être automatisées dans Azure DevOps • ZAP • Nmap • Sslyze • Etc. • Ce sont 2 efforts différents mais complémentaires qui se font en parallèle et en collaboration avec l’équipe d’automatisation
  10. 10. Chapitre 3: Un nouveau départ • Player 2 joined the game (spoiler, c’est moi) • On a besoin d’un plan – Backlog – 3 phases • Phase 1: tous les critères obligatoires sont automatisés, (minimum viable product) • Phase 2: tous les critères optionnels sont automatisés • Phase 3: on améliore les vérifications existantes • On a besoin d’une direction et d’une stratégie – Approche Breadth-First pour les 2 premières phases – Depth-First approach pour la 3e phase (amélioration continue) – Première phase doit être livré pour la date de l’ultimatum • On part à neuf, comme si les dernières semaines n’avaient simplement jamais existé
  11. 11. Chapitre 3: Un nouveau départ • On est pressé, donc on prend notre temps
  12. 12. Chapitre 3: Un nouveau départ • Unit Tests • Integration Tests • Pull Requests • Continuous Integration
  13. 13. Chapitre 3: Un nouveau départ
  14. 14. Chapitre 4: Premiers (vrai) pas • On livre une automatisation à la fois, en commençant par les plus faciles à implémenter • On livre un outil fonctionnel dans un environnement temporaire • En parallèle, on fait les démarches pour créer le produit – Paperasse administrative – Se perdre dans les processus pas super clairs pour un néophyte de création de produits – Environnements (DEV, QA, PROD) – Release pipeline – Build pipelines
  15. 15. Chapitre 5: Pendant ce temps • Automatisation des scans de sécurité – ZAP Passif – Nmap – Sslyze
  16. 16. Chapitre 6: Le grand jour • Les critères obligatoires de sécurités sont tous automatisés – du moins le minimum • Les premiers produits chanceux commencent à utiliser Azure DevOps pour faire leurs release – Début satisfaisant (de notre point de vue) – La vérification automatisée est solide et fiable
  17. 17. Chapitre 7: (Petite) Catastrophe
  18. 18. Chapitre 7: (Petite) Catastrophe
  19. 19. Chapitre 7: (Petite) Catastrophe
  20. 20. Chapitre 8: C’est optionnel • Pendant les prochains mois, implémentation des vérifications optionnelles – Test unitaires par rapport à la sécurité – Logs de sécurité – Threat Models – Etc.
  21. 21. Chapitre 8: C’est optionnel
  22. 22. Chapitre 9: Pendant ce temps (part II) • ZAP Actif – Roule automatiquement sur nos produits en QA les fins de semaines (ou quand l’on veut) – Utilise les tests d’intégrations pour aider ZAP (surtout pour les REST API purs)
  23. 23. Chapitre 10: Pousse pas trop • Idée: prenons avantage du fait que nous pouvons pousser de nouveaux critères de sécurité facilement! • Interdisons le support de TLS 1.0 du jour au lendemain! – Les services on seulement à passer à 1.2 en changeant une variable et c’est fini .. non..?
  24. 24. Chapitre 10: Pousse pas trop • Oh we were so wrong – Des services qui doivent attendre que les clients se mettent à jour – Plusieurs releases ont commencé à être bloqués – Nous avons inversé le changement
  25. 25. Chapitre 10: Pousse pas trop • Lesson: meilleure communication nécessaire
  26. 26. Chapitre 11: Amélioration continue • CredScan • Black Duck • Performance • Abandon de TLS 1.0 (progressif) • Vérification de secrets dans les logs • Amélioration de divers automatisation • Future – npm audit – OWASP Dependency Check? – Burp Enterprise? – Meilleur support pour les produits basés sur NodeJs – BinSkim?
  27. 27. Chapitre 12: Outro

×