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

1. Histoire vraie : Implémenter le
SecDevOps en entreprise

2. Votre Narrateur
• Guillaume Croteau
– Application Security Engineer II, Bentley Systems
– Génie Logiciel @ uLaval
– GIAC-GWEB
– (a essayé) OSCP

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. Chapitre 0: Prélude

5. Chapitre 0: Prélude

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. 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. 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. 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. 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. Chapitre 3: Un nouveau départ
• On est pressé, donc on prend notre temps

12. Chapitre 3: Un nouveau départ
• Unit Tests
• Integration Tests
• Pull Requests
• Continuous Integration

13. Chapitre 3: Un nouveau départ

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. Chapitre 5: Pendant ce temps
• Automatisation des scans de sécurité
– ZAP Passif
– Nmap
– Sslyze

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. Chapitre 7: (Petite) Catastrophe

18. Chapitre 7: (Petite) Catastrophe

19. Chapitre 7: (Petite) Catastrophe

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. Chapitre 8: C’est optionnel

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. 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. 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. Chapitre 10: Pousse pas trop
• Lesson: meilleure communication nécessaire

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. Chapitre 12: Outro