Dans un contexte de plus en plus agile, la sécurité traditionnelle n’est plus efficace.
En effet, lorsque la sécurité est traitée sous un aspect conformité, cela se résume à une liste interminable d’exigences de sécurité. Elles ne sont pas priorisées, parfois inutiles dans le contexte mais surtout, personne ne sait comment les implémenter style. Et en guise de recette sécurité, des tests d’intrusion sont menés tardivement et les correctifs sont très coûteux.
Qui plus est, la conception d’une application évoluent : déploiement dans le cloud (AWS, Azure, …), utilisation de service prêt à l’emploi (Discuss pour les commentaires),etc. Dans ce contexte, il est évident que les stratégies de sécurité traditionnelles de type “château fort” ne peuvent s’appliquer.
C’est alors que la notion “DevSecOps” est apparu, en 2012, avec pour objectif de développer des applications nativement sécurisée.
Dans un développement agile, toutes les fonctionnalités ne pourront être livrées en une seule fois. Les fonctionnalités seront livrées régulièrement par petite incrémentation. Il en va de même pour la sécurité : implémenter à chaque sprint une petite fonction de sécurité en priorisant les mesures les plus importantes. Cette sécurité en continue permet de tailler une armure sur mesure pour chaque application.
Pour formaliser vos risques, définissez les scénarios d’attaques réels et redoutés par le métier sous la forme de Abuser / Evil Stories (exemple : En tant que client, je veux modifier le prix d’un article pour le commander gratuitement).
Ces scénarios seront traduits en langage fonctionnel pour tester automatiquement (Exemple : avec Cucumber) le comportement de l’application et s’assurer qu’il est impossible d’y parvenir.
En sécurité, il n’est pas évident d’admettre que l’on s’est trompé.L’échec n’est pas dramatique tant que les erreurs sont corrigées rapidement. D’où l’importance d’obtenir du feedback rapidement.
De plus, il ne faut pas garder ses erreurs pour soi mais communiquer largement au sein de l’entreprise sur les erreurs faites par le passé pour éviter que cela se reproduise.
Ce principe, également désigné par “shifting security to the left”, vise à implémenter rapidement les mesures de sécurité que vous maîtrisez. Par exemple, il est préférable de réaliser des test automatiques à chaque livraison plutôt que d’attendre le déploiement en production pour mener un test d’intrusion.
Les compétences sécurité étant rares, de nombreuses équipes de développement attendent désespérément leur expert sécurité pour corriger des vulnérabilités.
Pour éviter cette situation, l’expert sécurité doit d’abord être pédagogue pour transmettre un peu de son savoir aux équipes de développement. Attention, il ne s’agit pas de former des experts sécurité mais simplement de transmettre le minimum nécessaire pour que l’équipe soit autonome pour traiter 80 % des cas.
Il est également important de mettre en place une collaboration entre les membres d’une équipe. Le “pair programming” et la revue de code permet de détecter les erreurs. Dans le cas de la vulnérabilité “Goto Fail” qui a touchée Apple en 2014, une revue de code aurait pu détecter le copier/coller excessif.
Dans le milieu de la sécurité, il est coutume de ne pas dévoiler son code source. Car on ne sait jamais, il y a peut être des failles et finalement, nous ne somme pas si fiers de notre code !
Si le développeur doit publier son code source, il prendra soin de le faire proprement (exemple : ne pas mettre de secret dans le git). Sans aller vers de l’Open Source vous pouvez dans un premier temps ouvrir votre code en interne.
Dans une application, très peu de code nous appartient… parce qu’on ne réinvente pas la roue à chaque fois, 90 % du code source provient d’une bibliothèque tierce que l’on a importé dans l’application.
Ces bibliothèque sont rarements analysées et aucune entreprise n’a les moyens (financiers et humains) de valider ces bibliothèques. Il existe de nombreux outils (Dependency Check, Snyk, RetireJS, …) pour vérifier l’utilisation de bibliothèque avec des vulnérabilités connues.
Le processus de livraison d’une application a été largement automatisé depuis l’apparition de la méthodologie agile et le phénomène s’est accentué avec la culture DevOps. Les usines de développement logiciel sont généralement constituée des étapes suivantes :
Les outils de sécurité sont :
| Type | Usage | Exemple | Phase |
| <Linter | Vérifie la syntaxe du code source. | ES Lint, Rubocop, ... | Code / Build |
| SAST (Static Application Security Testing) | Analyse le code source pour détecter des vulnérabilités | Sonar, Fortify, Checkmarx | Code / Build |
| DAST (Dynamic Application Security Testing) | Effectue des test de sécurité sur l’application | Zap, Fortify Webinspect, Gauntlt | Test |
| Vérification des dépendances | Vérifie l’absence de vulnérabilité connue dans les bibliothèques utilisé | Dependency Check, Black Duck, Xray | Build / Release |
| Security as Code | Vérifier les erreurs de définition d’infrastructure | Molecule (Ansible), Kichen (Chef) | Deploy |
| Supervision | Superviser et alerte en cas de suspicion d’attaque | Splunk | Operate |
Les outils de sécurité vous aideront certainement à améliorer le niveau de sécurité en obtenant un feedback rapide. Mais ce n’est pas suffisant et il faut également :
La culture du DevSecOps est avant tout une histoire d’humains.
(Par Romain Lecoeuvre de YesWeHack)
Le bug bounty est une pratique de Crowd Security dont l’objectif est de faire tester la sécurité de votre application par la communauté.
La plateforme “Bounty Factory” est proposé par YesWeH4ck est un moyen pour mettre en relation les chercheurs en sécurité et les équipes de développement ayant besoin de faire tester leur code.
Le bug bounty est un moyen de tester la sécurité de votre application par des milliers de chercheurs. Ces derniers sont récompensés pour chaque vulnérabilité découvertes par des primes, des cadeaux ou par des points.
Il y a 3 types de Bug Bounty :
Pour commencer, l’organisation doit définir les règles du jeux de son bug bounty :
La communauté réalise différents tests de sécurité. Lorsqu’un chercheur trouve une vulnérabilité, il rédige un rapport qui sera communiqué à l’organisme commanditaire.
Par la suite, l’organisme doit qualifier la vulnérabilité remontée par le chercheur :
L’organisme apporte les correctifs nécessaires pour corriger la vulnérabilité. Le chercheur peut être sollicité pour effectuer un contre-audit afin de s’assurer de l’efficacité du correctif.
Le bug bounty vous permet de faire de la sécurité en continu tout au long de votre cycle de développement agile. L’équipe de développement monte en compétence au fur et à mesure des vulnérabilités découvertes. Osez vous mettre à nu en créant votre programme de Bug Bounty !
Le DevSecOps, ça coûte cher. Comment fait-on avec une équipe restreinte ?
Ce n'est pas forcément cher car l'objectif n'est pas d'embaucher de nouvelles personnes pour faire du DevSecOps. Mais il faut former les personnes déjà présentes et répartir les compétence sécurité au sein de l’équipe.
Pour les applications développées par des prestataires externes, comment contrôler le niveau de sécurité et le respect des exigences ?
C'est la question fondamentale des projets en agile. Il ne faut pas traiter ses prestataires comme des exécutants mais comme des partenaires. Si le prestataire et le client n'ont pas la même vision d'implémentation de la sécurité, il faut changer de prestataire.
L’automatisation des tests de sécurité et le bug bounty permettent déjà quelques contrôles. Concernant la qualité, il faut vraiment entretenir une relation de partenariat.
Et le legacy alors ? (Cobol)
Il y a des prérequis pour faire du DevSecOps. Il faut déjà faire du DevOps, du projet agile, de l'intégration continue. Il faut y aller étape par étape.
Non, ce n'est pas facile d'appliquer le DevSecOps sur des applications legacy (code non maintenu, perte de connaissance,...).
Oui, c'est plus facile avec des architectures orientées services ou micro services, sur des features teams, sur des petits projets... que sur des applications monolithiques.
Le DevSecOps s'approprie donc davantage pour les projets modernes.
Est-ce que le bug bounty est plus efficace qu'une mise en place d'une chaîne DevSecOps ?
Il ne faut pas comparer les deux. C'est complémentaire. Le bug bounty a toute sa place mais ne peut pas se substituer aux compétences de l’équipe et aux outils de sécurité.
Une feature team est une équipe pluridisciplinaire (UX, OPS, PO, dev,...). Il faut former l'ensemble de l'équipe, même le métier qui doit se prononcer sur les aspects fonctionnels de la sécurité (ex : gestion du cycle de vie des mot de passe, mot de passe oublié, ...). Le métier fait donc partie prenante des enjeux de sécurité.
Lors d’un projet de transformation vers DevOps, quand faut-il intégrer la Sécu ?
Il faut intégrer la sécurité dès que possible car l'architecture et les outils doivent être conçus en collaboration avec la sécurité.