Origine du DevOps et du DevSecOps

Le DevOps est une philosophie née suite aux mouvements Agile et Lean des années 2000-2005. Ces mouvements avaient pour objectifs de rendre le développement plus flexible et plus rapide, tout en bâtissant des applications de qualité, centrées sur les besoins des utilisateurs. L’application de ces méthodes a augmenté la capacité de livraison des équipes de développement et a changé la planification de leurs besoins en infrastructure. Cependant, les processus opérationnels n’étaient pas adaptés à cette nouvelle réalité : cela a contribué à créer des délais et des frictions entre les équipes de développement et d’opérations TI. À la source de cette dichotomie, notons que la raison d’être des équipes de développement est de mettre de l’avant des nouvelles fonctionnalités alors que celle des opérations est d’assurer la disponibilité et le rendement des services et applications.

La philosophie DevOps est donc arrivée vers 2009 afin d’amener des pistes de solution à ces défis. Parmi les objectifs de la philosophie DevOps notons :

Encadrer les équipes de développement et d’opérations afin de briser les silos qui séparent les spécialistes.
Raccourcir les cycles de développement en effectuant des mises en production plus fréquentes et plus fiables.
Livrer des produits, des fonctionnalités et des services de qualité.
Mettre en place une démarche d’optimisation, d’évolution et d’apprentissage continue.

Afin d’accomplir ces objectifs, la philosophie DevOps repose sur quatre piliers : « Culture, Automatisation, Measures, Sharing » (CAMS).

Depuis quelques années, nous voyons maintenant se populariser un nouveau terme, celui de « DevSecOps » . Le « DevSecOps » consiste à ajouter un nouvel objectif, soit celui d’intégrer la sécurité et la gestion du risque de façon transparente dans l’ensemble du processus de développement, plutôt que de simplement rajouter quelques tâches liées à la sécurité à la fin du projet.

Pourquoi le DevSecOps?

Afin de demeurer compétitives, les entreprises doivent livrer de nouveaux produits et de nouvelles solutions toujours plus vite et à moindre coût. Les mouvements Agile, Lean et la philosophie DevOps y contribuent grandement par la standardisation et par l’automatisation. Toutefois, des risques non-négligeables découlent de cette accélération : ceux liés à la sécurité informatique. Le temps entre le développement et la mise-en-production est réduit à quelques heures, voir même à quelques minutes.

De nouvelles vulnérabilités sont constamment trouvées touchant les services et les applications d’infrastructure qui constituent les fondations d’Internet. La gestion de la sécurité doit s’adapter et en l’intégrant dans le DevOps, nous nous donnons des moyens pour non seulement conserver des environnements sécuritaires, mais également pour améliorer, simplifier et accroître la sécurité de nos environnements.

Le besoin

Historiquement, dans le cadre des projets informatiques, la sécurité est souvent traitée de façon isolée, distincte et non intégrée aux autres étapes du processus de livraison. Plus spécifiquement, dans le cadre d’un projet de développement applicatif, il n’est pas rare de ne voir aucune tâche, ni aucune phase du projet traitant de la sécurité de l’application. Souvent, dans les semaines précédant la mise en production, quelques tâches seront ajoutées en catastrophe afin de satisfaire des besoins de conformité. C’est malheureusement souvent à ce moment que les ressources de sécurité apprennent l’existence même du projet… Ces derniers précipiteront alors quelques vérifications de sécurité ou peut-être un test d’intrusion applicatif… si nous sommes chanceux.

Si des vulnérabilités sont découvertes à ce stade, elles seront potentiellement balayées sous le tapis afin de ne pas retarder la mise en production et afin de rencontrer les objectifs d’affaires, introduisant ainsi des risques de sécurité. Dans le cas contraire, afin de remédier à la situation, il faudra potentiellement corriger des bogues applicatifs, corriger des configurations, ou revoir la conception et le design de l’application. Il faudra ensuite effectuer de nouveaux tests avant de passer en production. Tous ces ajouts auront pour effet de repousser la date de lancement de l’application ou de la fonctionnalité développée. La correction de code à cette étape de la réalisation d’une application s’avère très coûteuse dans un mode de livraison traditionnel.

L’implantation de la philosophie DevOps permet de simplifier les mises en production et d’accélérer la livraison de nouvelles fonctionnalités aux clients et aux demandeurs. La fréquence des publications de nouvelles versions des applications est passée de parfois une à deux fois par année à des déploiements quotidiens et parfois même à plusieurs déploiements par jour. Les entreprises n’ont d’autre choix que d’adopter le DevOps si elles désirent demeurer en affaires. Sinon, leurs clients vont se tourner vers des compétiteurs plus agiles et rapides qui adoptent ces méthodes et qui sauront ainsi mieux répondre à leurs besoins. Cela est particulièrement vrai pour les grandes entreprises qui doivent rivaliser avec des « start-up », beaucoup plus « lean ». Ces « start-up » n’ont pas les mêmes structures et processus en place, elles n’ont également généralement pas les mêmes besoins de conformité. Cela leur permet d’avoir un cycle de livraison très rapide qui bénéfice grandement au client. En contrepartie, ces déploiements continuels et l’ajout de nouvelles fonctionnalités peuvent présenter de nouveaux risques. Par exemple, de nouvelles vulnérabilités peuvent constamment être introduites dans le code et si le processus de déploiement n’est pas adéquat, ces vulnérabilités pourront se retrouver en production et ne pas être détectées pendant plusieurs jours, semaines, mois… si elles le sont.

En parallèle à cette nouvelle réalité, de nouveaux enjeux de sécurité ont également fait surface dans les dernières années. Parmi ceux-ci, notons les vulnérabilités découvertes plus fréquemment dans les logiciels libres. Ces logiciels sont utilisés par tous et font partie de nos infrastructures ou sont des composantes de nos applications. Il y a eu certaines vulnérabilités plus importantes telles que OpenSSL, Bash et Apache Struts qui ont fait les nouvelles, mais de nouvelles vulnérabilités sortent toutes les semaines touchant les WordPress, Drupal, Joomla et autres applications Web que nous retrouvons maintenant dans chacune de nos entreprises. Il faut détecter et corriger rapidement ces vulnérabilités lorsqu’elles sont découvertes.

L’implantation d’une philosophie « DevSecOps » permet de gérer la sécurité d’une application en adressant les risques et les vulnérabilités qui lui incombent tout au long de son cycle de développement et de son cycle de vie.

Les objectifs du DevSecOps

Voici les principaux objectifs que nous désirons atteindre en adoptant une philosophie « DevSecOps » :

Meilleure efficacité opérationnelle entre le groupe de sécurité informatique et les autres groupes informatiques.
- Permet d’améliorer la collaboration entre les différentes ressources des équipes informatiques dans l’organisation.
- La sécurité informatique occupe ainsi davantage un rôle de facilitation et de création de valeur.
- Il faut briser les silos entre les équipes de sécurité et les équipes opérationnelles. Les ressources de sécurité doivent faire partie intégrante de l’équipe de DevOps.
Identifier les problèmes de sécurité tôt dans le processus de développement et de livraison plutôt que de les découvrir une fois que l’application soit complétée et en production.
- Mouvement « Shift Left » visant à considérer les aspects de sécurité de l’application dès le début et tout au long du cycle de développement, de déploiement et de vie de l’application.
Détecter les nouvelles vulnérabilités dans nos applications et dans ses diverses composantes plus rapidement.
- De nouvelles vulnérabilités dans les applications, leurs composantes et les infrastructures qui les hébergent sont constamment découvertes.
- Il faut des moyens pour être en mesure d’agir plus rapidement.
Permettre aux ressources de consacrer davantage de temps à des tâches à plus haute valeur pour l’organisation que sur des tâches opérationnelles.
- La rareté et le coût de plus en plus élevé des spécialistes en sécurité nous amène à optimiser leur travail afin qu’ils puissent se consacrer à des tâches ayant davantage d’impact et de bénéfices pour l’entreprise que sur des tâches opérationnelles de moindre valeur ajoutée.
Augmenter le ROI des investissements en sécurité informatique. L’adoption d’une philosophie « DevSecOps » permet d’obtenir un meilleur retour sur les investissements faits en sécurité informatique :
- Une entreprise maîtrisant les méthodologies DevOps / « DevSecOps » peut déployer jusqu’à 46x plus rapidement qu’une entrepris * efficace. Cela augmente la satisfaction des clients et la rentabilité de l’entreprise.
- En adoptant les méthodologies « DevSecOps », il est également possible de revoir à la basse le calcul de perte annualisée (ALE = SLE × ARO).
- Les méthodologies « DevSecOps » augmentent l’efficacité des ressources, permettant ainsi d’éviter de croître la taille des équipes.
Minimiser le temps de reprise suite à un désastre
- L’« Infrastructure As Code » (IAC) est un concept fondamental au DevOps et ainsi donc au « DevSecOps ». En IAC, les infrastr * informatiques sont traitées comme du logiciel : elles sont définies dans des fichiers de configuration et dans des scripts q * exécutés pour créer les différents environnements. Ces fichiers sont testés en utilisant des stratégies provenant du dévelo * logiciel telles que les tests unitaires et les tests d’intégration (dans un environnement Microsoft, Pester peut d’ailleurs être * pour les tests unitaires, dans les environnements davantage Linux / Open Source, Serverspec peut être utilisé à cette fin). En I * fichiers de configuration des environnements sont gérés sous contrôle de version.
- En cas d’incident ou de désastre, il est aisé et rapide de remonter les environnements complets en exécutant les recettes de déploi * Les possibilités d’erreur humaines sont inexistantes et nous sommes certains de revenir à une configuration identique à celle en pro * préalablement à l’incident.

Comment implanter une philosophie DevSecOps?

Afin d’implanter une philosophie « DevSecOps », la participation de la haute direction est requise, tout comme l’est celle des joueurs œuvrant dans les équipes informatiques de développement, d’opérations et de sécurité.

Voici maintenant les principales étapes requises afin de parvenir à amener ce changement de culture que consiste le « DevSecOps ».

Gagner l’appui de la haute direction en démontrant la valeur.
- Tout comme pour l’implantation d’une philosophie DevOps, l’implantation du « DevSecOps » changera les façons de travailler de gens œuvrau sein de différentes équipes et de différents groupes : il sera beaucoup plus aisé d’amener ces gens (et leurs dirigeants) à travailconjointement, en collaboration, dans un nouveau cadre de travail, en ayant l’aval de la très haute direction de l’entreprise.
Auditer, inventorier et réviser l’environnement actuel : les infrastructures, le code des applications, les processus et corriger les problèidentifiés.
- Afin de bien comprendre le fonctionnement de l’environnement et sa posture (ex. application des correctifs de sécurité).
- En effectuant l’analyse des risques et des menaces. Le « SANS Institute » recommande d’effectuer un exercice d’analyse de menaces avantpasser au « DevSecOps ». Cette analyse permettra de déterminer les menaces auxquelles notre système sera confronté, le type etsensibilité de nos données, les contrôles en place ainsi que les écarts entre les menaces et les contrôles que nous devrions priorisercombler.
Automatiser la sécurité le plus possible:
- Les tests et contrôles de sécurité doivent être intégrés et se retrouver à toutes les étapes du cycle de développement de l’applicatiVoici, selon Gartner, la représentation du cycle « DevSecOps » :
  
  Gartner – Intégration DevSecOps dans le DevOps
- Ces tests doivent être exécutés de façon automatisée après chaque déploiement de code.
- Il est nécessaire d’utiliser des outils afin de tester les applications. Des méthodes statiques et dynamiques doivent être combinées.
  - Les méthodes de type « Static Application Security Testing » (SAST) permettent d’analyser directement le code source des applicatiafin d’y détecter des failles. Elles peuvent être intégrées dans le pipeline d’intégration continue. L’avantage de cette technique que les problèmes sont détectés plus tôt dans le processus et il est donc plus rapide et facile de les corriger. En revanche, ceétape peut s’avérer coûteuse en temps et afin de ne pas allonger inutilement le délai du « build », elle sera souvent uniquemappliquée une fois par jour sur le « nightly build ». OWASP nous présente une liste exhaustive d’outils pouvant être utilisés : Source Code Analysis Tools.
  - Les méthodes de type « Dynamic Application Security Testing » (DAST), quant à elles, sont exécutées contre des applicatilorsqu’elles sont déployées (mais pas en production!), donc à la fin du processus d’intégration continue. Ces méthodes permettent aide découvrir des vulnérabilités qui ne pouvaient pas être détectées à la seule révision du code source. Toujours selon OWASP, voquelques outils dynamiques pouvant être utilisés : Vulnerability Scanning Tools.
Commencer un programme de sensibilisation et de formation à la sécurité dès le jour 1.
- Tous les intervenants du cycle DevOps doivent être sensibilisés et formés.
- À la suite de l’embauche de nouvelles ressources, la formation quant aux bonnes pratiques en sécurité doit commencer dès leur premijournée.
- La formation et la sensibilisation est un processus continuel et perpétuel.
- Les développeurs doivent apprendre à coder leurs applications de façon sécuritaire. Une référence intéressante à ce sujet est le « Rugged Manifesto ». Après tout, comme l’a dit Ryan O’Leary de WhiteHatSecurity : “The best way to prevent a vulnerability is to never code it the first place”.
Valider les dépendances dans le code de l’application régulièrement.
- Les développeurs réutilisent constamment des modules et des composantes provenant de différentes sources. L’accès à de nombreux logicilibres permet aux développeurs de gagner grandement en efficacité et réutilisant du code existant plutôt qu’en récrivant du code.
- Des vulnérabilités peuvent exister ou pourront être découvertes dans le futur concernant ces modules, rendant vulnérable l’application les utilise. Des outils de vérification de dépendances et de vulnérabilités peuvent s’intégrer au pipeline d’intégration continue afinmitiger cette problématique.
Standardiser l’environnement.
- Tout comme dans le DevOps, la complexité est un ennemi pour le « DevSecOps ». Il est important de standardiser les environnements etréutiliser les mêmes technologies, applications et outils lorsque possible.
- À chaque nouvelle technologie que l’on introduit, nous introduisons également une nouvelle source de vulnérabilités potentielles. surcroît, il faut également mettre-à-jour, maintenir, monitorer, optimiser et également développer une expertise face à cette technolog

Conclusion

Gartner – Intégration DevSecOps dans le DevOps

La philosophie « DevSecOps » se résume à intégrer les aspects de la sécurité informatique dans le DevOps plutôt que de les traiter en aval. Cela consiste à renforcer les compétences des développeurs et des différents joueurs, à automatiser des tests aux différentes étapes du cycle « Dev(Sec)Ops » et à décomplexifier les environnements informatiques. Cependant, plus que de simples étapes à accomplir, le « DevSecOps » est un changement de culture qu’il faudra adopter et intégrer. Pour faciliter ces changements, l’appui de la haute direction de l’entreprise est primordial.

Ultimement, le terme « DevSecOps » ne devrait pas exister : la sécurité doit faire partie intégrante de la culture des équipes TI et doit être considérée en permanence dans toutes les décisions informatiques. La sécurité est une composante essentielle du DevOps.

La philosophie DevOps permet aux équipes informatiques de répondre aux réalités découlant de l’adoption des méthodologies de développement Agiles. En brisant les silos, en favorisant la communication entre les intervenants (clients, développeurs, opérations, sécurité), en automatisant les tâches opérationnelles, le DevOps permet ultimement d’accélérer la livraison de produits et de fonctionnalités, répondant aux besoins réels des clients.

Finalement, le DevOps est un processus d’évolution et d’apprentissage continu où il n’y a pas de destination finale : l’objectif est de constamment viser l’amélioration. Références :

Devops DevSecOps