Histoire vraie : Implémenter le
SecDevOps en entreprise

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

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)

Chapitre 0: Prélude

Chapitre 0: Prélude

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

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?

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)

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

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é

Chapitre 3: Un nouveau départ
• On est pressé, donc on prend notre temps

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

Chapitre 3: Un nouveau départ

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

Chapitre 5: Pendant ce temps
• Automatisation des scans de sécurité
– ZAP Passif
– Nmap
– Sslyze

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

Chapitre 7: (Petite) Catastrophe

Chapitre 7: (Petite) Catastrophe

Chapitre 7: (Petite) Catastrophe

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.

Chapitre 8: C’est optionnel

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)

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

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

Chapitre 10: Pousse pas trop
• Lesson: meilleure communication nécessaire

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?

Chapitre 12: Outro