Pour ce premier épisode de 2021, nous sommes heureux de vous présenter notre Maître Jedi de la pratique DevSecOps.
Directeur principal – Stratégie livraison de produits chez In Fidem, Simon Bérubé s’assure d’intégrer les meilleures pratiques DevSecOps aux équipes pour accélérer la livraison de valeur et minimiser le gaspillage dans un contexte où les ressources sont rares.
Véritable couteau suisse, Simon a commencé sa carrière en tant que développeur avant d’être expert en cybersécurité et product owner de services infonuagiques.
Grâce à ses expériences, il comprend parfaitement les différentes dynamiques d’affaires et il sait avec habileté intégrer la sécurité aux trois grands piliers de la livraison DevOps : l’agilité, l’infonuagique et l’automatisation.
Aujourd’hui, Simon a accepté de démystifier le concept DevSecOps en répondant à quelques-unes de nos questions pour notre podcast INTRASEC, la chaîne de cybersécurité d’In Fidem. Il nous explique comment mettre en œuvre la sécurité à tous les niveaux et pour tous les environnements en tirant profit d’outils automatisés afin d’accélérer votre performance.
À travers votre carrière, vous avez pu toucher aux trois grandes composantes du DevOps – l’agilité, l’infonuagique et l’automatisation – et, maintenant, vous y ajoutez une 4e composante qu’est la sécurité ? Pouvez-vous nous en dire plus ?
Le DevOps vise à accélérer la livraison de valeur et donc la qualité car cela a un impact direct sur notre marque et la perception de nos clients. On ne veut plus d’idée qui prenne deux ans et demi à développer et qu’une fois livrée, cela ne corresponde plus au besoin du client.
Ce qu’on veut, c’est réagir rapidement aux besoins du marché et c’est pour ça qu’on va faire du DevOps.
Et forcément, lorsqu’on parle de qualité et qu’on pense aux fuites de données, ou de cryptolockers qui demandent des rançons, ça devient nécessaire que la qualité soit également valable en matière de sécurité.
Pour cela, on doit s’assurer que la sécurité ne soit pas considérée à la fin, mais bien en amont, pendant qu’on construit les fonctionnalités. Ce qui signifie qu’elle doit être intégrée dès la conception.
Lorsqu’on pense au DevOps, cela implique de réfléchir à comment on va bâtir nos logiciels, nos architectures, automatiser… On s’attend donc à avoir des logiciels relativement robustes et sécuritaires. Néanmoins, si on comprend bien ce que vous dites, ce n’est pas le cas. Pourquoi les logiciels ne sont pas toujours sécuritaires avec le DevOps « normal » ?
Souvent en développement, on raisonne en termes fonctionnels. On se concentre à livrer de la valeur au client, donc on va rapidement tomber en mode « solutions ». On va dire : « Ok ! Le client veut ça, alors on va prendre telle solution ou tel produit ou changer telle fonction pour répondre au besoin ». Mais il faut prendre le temps de faire un pas en arrière et se poser les bonnes questions : quelles données vont être manipulées ? Est-ce que ce sont des données sensibles ? Est-ce que ces données ont une tolérance à être publiques ? Est-ce que ces données peuvent être altérées sans dommage ? ».
Donc, l’idée, c’est d’amener les trois piliers de la sécurité dans les réflexions des fonctionnalités qu’on doit bâtir.
Et une fois qu’on a répondu à ça, si on a deux semaines, on va appliquer le niveau de sécurité qu’on peut [plutôt qu’une sécurité parfaite]. Cela force une meilleure évaluation du risque qu’on est prêt à accepter pour chaque fonctionnalité que l’on développe.
Comment amène-t-on la sécurité à la pratique DevOps, surtout pour une organisation qui n’aurait pas intégré ces considérations-là dans son approche ?
Il y a plusieurs façons de l’amener. Si tu es dans une organisation qui possède des experts en sécurité, il suffit de les amener dans les sprints et de les faire participer à la livraison de chaque incrément, ce qui fait un effet de diffusion.
Au début, ça va être l’expert de sécurité de l’intégrer. Mais après quelques semaines, l’équipe va développer les mêmes réflexes et ça va lui permettre de gagner une certaine maturité. Si on n’a pas d’expert à l’interne, c’est possible d’aller sur le marché pour trouver des conseillers qui vont aider l’équipe à aller chercher ces compétences.
Il faut aussi une volonté de l’organisation. Les programmes de sécurité partent souvent de la tête de l’organisation. Il faut qu’elle supporte les équipes pendant qu’elles prennent le temps de se développer et de s’organiser pour livrer des logiciels sécuritaires. Parce que c’est clair que si ton gestionnaire te dit tout le temps « Vite, vite, vite, c’est pour hier qu’on a promis ça au client », tu comprends comme moi que ça sera difficile de pousser les éléments de sécurité.
Bref, ça prend aussi une volonté de la gestion d’inclure la sécurité dans la qualité du produit.
Vous touchez un point assez important. Un des plus gros freins à l’adoption de pratiques de cybersécurité dans le développement, c’est la pression du management – volontairement ou involontairement – qui va trouver des raisons pour ne pas les mettre en place. Est-ce que le DevOps, la pratique semblant être très orientée sur la livraison de valeur, trouve une meilleure manière d’intégrer les considérations de sécurité ? Ou est-ce que, malgré tout, ça reste un coût qu’il faut être prêt à payer ?
D’entrée de jeu, le plus grand changement qu’il faut apporter, c’est de prendre la sécurité comme un coût et la transformer en valeur. Pour nos clients et nos partenaires, on voit de plus en plus que la sécurité est une source de valeur. Sur le marché, il y a aussi de plus en plus de partenaires qui demandent des informations sur les pratiques de développement pour s’assurer qu’ils sont sécuritaires.
Il faut donc vraiment monter ces considérations de sécurité au même niveau des autres critères de qualité.
Évidemment, il y a une maturité à prendre. C’est certain que pour ton premier sprint, on ne s’attend pas à ce que le premier incrément que tu livres soit aussi sécurisé que celui du département américain de la défense.
Par contre, il faut prendre une orientation sécuritaire d’entrée de jeu et se demander comment on peut bâtir les choses de la manière la plus sécuritaire possible. Et je vais annoncer le niveau de vulnérabilité de mes composantes.
Par exemple, si je sais que mon composant n’est pas sécuritaire. Est-ce que c’est faute de temps ? Est-ce que le niveau de complexité était trop grand pour que je le livre en deux semaines ?
Dans une approche sécuritaire pour un service, on pourrait dire « Mon application est sécuritaire si j’ai un tel niveau de tolérance face à la confidentialité, à l’intégrité ou la disponibilité ».
Pouvez-vous nous parler du « degré de sécurité » qu’on va annoncer avec un service. Par exemple, pouvez-vous nous dire à quel point les gens sont ouverts et capables de comprendre ces subtilités ?
C’est une très bonne question. Pas tout le temps. L’humain a tendance à croire que ça ne lui arrivera pas.
Par contre si on regarde d’un point de vue organisationnel, souvent ton client va être interne. Et lorsque tu as un client interne, on peut lui dire de commencer à l’utiliser pour donner du feedback et valider les besoins. Cela permet de l’impliquer et d’avoir son retour d’expérience, ce qui est très précieux.
À l’externe, si on regarde la vitesse avec laquelle on accepte les conditions d’utilisation sur les sites web, les applications, etc. Cela montre qu’on ne les lit pas…
Cela étant dit, je pense qu’on ne peut pas trouver de recette universelle et ça dépend vraiment du contexte de ton application. Ça dépend du type de données qui est manipulé, etc. Au final, ça reste un exercice d’évaluation du risque.
Comment valider la sécurité ? Quelles sont les pratiques ?
Il y a différentes approches qui peuvent être mises de l’avant.
Une des premières, c’est prendre une approche « white box », c’est-à-dire de valider que l’application a les comportements attendus. Par exemple, qu’on authentifie un utilisateur avant de lui permettre d’atteindre une certaine section. On peut donc mettre des tests dans le code qui vérifient que l’authentification est présente un peu comme ce qu’on ferait pour des tests fonctionnels sur les concepts de sécurité.
On a aussi une approche un peu plus « black box » où tu ne sais pas trop ce que tu cherches, mais tu as des robots qui, dans un environnement contrôlé, essaient d’abuser de ton application comme le ferait un pirate.
Donc il y a plein de méthodes connues et ces robots sont programmés pour tester les attaques actuelles et passées. Ils vont simuler les attaques et donner un rapport à l’équipe.
Ces deux méthodes respectent énormément la philosophie de DevOps parce qu’on cherche à faire, c’est le « fail fast ». On veut avoir les échecs les plus proches de la source.
Par opposition avec les environnements de développement plus traditionnels où on planifie, on développe, on fait des environnements de test, on fait des tests manuels ou pas et, là finalement, on découvre qu’il y a des erreurs.
Avec le DevSecOps, ce qu’on veut, c’est qu’à 15h, le développeur soumet son code et à 16h, il est déjà averti qu’il y a une vulnérabilité parce que tous les tests se sont faits automatiquement. Donc forcément le lendemain, il va commencer en corrigeant cette vulnérabilité-là.
Encore plus proche que le développement, c’est de ramener ces problématiques au moment où on fait de la conception en équipe. C’est de se demander au moment où on pense à une nouvelle fonctionnalité, comment la donnée va circuler à travers la fonctionnalité, quels sont les vecteurs que pourrait prendre un attaquant pour compromettre les données, l’intégrité du système, etc.
Donc si on capte les problèmes lors de la conception, c’est gagnant parce qu’on est le plus proche possible de la source.
Sinon, il y a aussi des outils qui se mettent dans l’interface du développeur et qui scannent le code qu’il est en train d’écrire et vont l’avertir s’il utilise un pattern qui est à risque.
En résumé, au niveau de la conception, on va devoir déterminer les informations qu’on va obtenir et gérer, si elles peuvent être transformées ou pas et par qui. Et pour ces choses-là, on peut faire des tests fonctionnels. Une fois que ça, c’est fait, on peut aussi ajouter des outils qui vont faire une inspection plus « profonde », qui peuvent identifier des vulnerabilités, etc. Et finalement, on peut mettre des plug-ins dans notre environnement de développement qui vont nous éviter de faire des erreurs bêtes et méchantes.
Exact. Il y a deux grands concepts là-dedans : le code statique et le code dynamique.
Il y a des tests qui sont plus statiques et qui vont analyser la structure du code. Et il y a des tests qui sont plus dynamiques, et qui vont tester des scénarios et des fonctionnalités sur ta solution une fois déployée.
C’est un peu comme ce que font les gens en sécurité offensive, mais ils sont débordés, alors ils ne peuvent pas tout le temps venir tester ta solution.
Donc la solution, c’est d’automatiser une partie de ces tests et de les intégrer à tes pipelines. Alors le rôle de l’équipe de sécurité offensive devient celui de valider ce pipeline, de voir s’il est fiable, de voir si ça serait possible d’ajouter du code en production qui éviterait tous mes contrôles, etc.
Et comme ça, on gagne en vitesse parce qu’on a automatisé une partie des tests d’intrusion, mais on se garde une possibilité d’amener des experts pour tester et voir si notre chaîne est aussi solide qu’on le pense.
À quel point est-ce que les outils d’analyse de code peuvent être utilisés off the shelf et à quel point demandent-ils à être configurés pour notre environnement spécifique ? Si on utilise un plug-in, on s’attend à ce qu’il vienne avec une liste de meilleures pratiques à tester, et en même temps, il faut le configurer. Quel est le pourcentage de configuration auquel on devrait s’attendre ?
Il faut savoir qu’en DevOps, tes environnements se déploient à partir du code source; tu n’attends pas un administrateur système pour faire partir une machine virtuelle, etc. Donc tu vas écrire du code pour spécifier les caractéristiques des machines que tu veux, etc. Et après, tu devras écrire un test pour t’assurer qu’elles respectent les lignes directrices d’endurcissement d’un système d’exploitation, d’un serveur web, etc.
Bref, il faut faire des tests pour ton propre code, mais aussi pour les scanners automatisés; c’est très rare les outils où tu n’as rien à faire!
Quand les experts [de pénétration] viennent tester les pipelines DevOps, quelles sont les erreurs qu’ils voient typiquement ? Est-ce qu’il y a des low hanging fruits auxquels il faut faire attention ?
Une version d’un système d’exploitation ou une langue qui est trop ancienne et qu’on n’a pas mise à jour parce que « ça marche encore, je n’y touche pas ».
Or à un moment donné, ces versions deviennent désuètes et des vulnérabilités connues sont publiées. Si on ne les met pas à jour, ça devient une excellente porte pour les pirates. D’ailleurs, c’est ce qu’ils scannent.
Il y a aussi les identifiants. Des fois, il y a des mots de passe qui traînent dans le code source. Ce qui est à proscrire dans les bonnes pratiques DevOps. Il y a juste les robots qui devraient connaître ces secrets.
Ce qui rappelle aussi l’importance de l’authentification multifacteur. Parce que même si un attaquant trouve des mots de passe, il va quand même lui manquer la clé pour s’authentifier en notre nom.
Si on comprend bien, le DevSecOps est un processus en continu. Et si on fait appel à vous et que vous arrivez en tant qu’expert, vous allez faire une analyse. Pouvez-vous nous décrire les étapes ?
Tout d’abord, ça commence par une introspection à l’interne. Par exemple, une équipe qui cherche à faire de la livraison agile, mais qui ne remplit pas ses engagements ou bien qui promet des choses, mais qui ne livre pas. Dans ces cas-là, elle va peut-être avoir besoin d’un coach agile pour aider la livraison en tant que telle.
Si tu as une équipe qui est déjà mature, peut-être que c’est l’élément de sécurité qui manque. Et, dans ce cas-là, il va falloir identifier les manquements et déterminer quels sont les problèmes, les insatisfactions de la business face à ton équipe. Parce que, forcément, si tu vas chercher de l’aide, c’est qu’il y a des choses qui ne sont pas atteintes par l’équipe.
Dans le cas précis de la sécurité, ce qu’on va faire, c’est aller voir les équipes et évaluer leur niveau de connaissance en sécurité, on va regarder le programme de sécurité au niveau business. Comme je le mentionnais au début, il y a une volonté de l’organisation de rendre la business sécuritaire, alors on va regarder le programme. Est-ce qu’il y a des objectifs clairs ?
Si le programme a des manquements, on va travailler sur le programme de sécurité. Est-ce qu’il y a des plans de formations en sécurité pour les équipes ? Est-ce que l’équipe peut se former continuellement ou est-ce qu’elle doit livrer des features 40h semaine ? Si c’est le cas, on va travailler pour intégrer des routines de formation pour que les développeurs puissent augmenter leurs compétences progressivement et en continu.
Et une fois qu’on a regardé ça, on va peut-être regarder les outils. Est-ce qu’on a les bons outils pour détecter tous les scénarios ? Peut-être qu’il y a des manquements au niveau de l’outillage. On va peut-être faire des preuves de concepts, etc.
Alors, si on comprend bien, les questions techniques viennent à la fin…
Oui. Parce que la sécurité doit être perçue comme une source de valeur, pas un coût. Cependant, soyons factuels, la sécurité, ça a un coût.
Cela demande le travail d’experts, de la formation, des outils, etc. Alors c’est important d’appliquer cette sécurité en fonction du risque. Si les abus de sécurité n’ont aucun impact, peut-être qu’on va juste décider de ne pas investir là. Par contre, il y a des endroits où on ne peut pas baisser la garde et c’est à ces endroits qu’il faut mettre l’effort et l’énergie.
Alors c’est important de comprendre les lois auxquelles l’entreprise est assujettie, les programmes de sécurité, les standards de livraison et d’appliquer ça à nos équipes, de regarder le résultat et de dire « Ah! Pour atteindre nos exigences, il nous manque un expert » ou « Je n’ai pas encore l’outil pour répondre à ces exigences ».
C’est donc une fois qu’on aura identifié ces exigences qu’on va amener ça dans les chaînes de montage, parce qu’il y a quand même beaucoup d’efforts qui sont nécessaires pour industrialiser tout ça.
Et si on industrialise quelque chose qui n’est pas nécessaire, c’est du gaspillage et c’est ce qu’on essaie d’éviter.
Donc en résumé : lorsqu’on fait une analyse du risque en tant qu’organisation, il y a des obligations qu’on doit respecter. Et quitte à devoir les respecter, le DevSecOps, d’une certaine manière, cherche à transformer ce coût en valeur parce qu’on a des pratiques de développement plus robustes, qui restent orientées vers la livraison de fonctions pour les clients.
Exactement.
Retrouvez l’intégralité de son interview (en français) sur Ausha, Apple Podcasts, Spotify, Google Podcasts, Podcast Addict.
