Compte-rendu de la Matinale “DevSecOps League : sortez la sécurité de l’obscurantisme” 4 octobre 2018. Par Didier Bernaudeau

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.

Comment mettre en place des pratiques DevSecOps dans votre entreprise ? Par où commencer ? Comment agiliser la sécurité ? La tribu Appsec d'OCTO Technology vous apporte ses réponses...

• Retrouvez la présentation complète de la Matinale sur SlideShare.
• La vidéo de la Matinale est également disponible sur octo.tv

Axe 1 - Agiliser la Sécurité

Sécurité Continue

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.

Scénario d’attaque

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.

Admettre l’erreur

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.

Safer Sooner

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.

Culture de la collaboration

Transmettre son savoir

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.

Revue de code

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.

Se mettre à nu

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.

Automatisation

Les bibliothèques

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.

Les outils de sécurité

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 :

Conclusion

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 :

• Former les équipes à la sécurité
• Faire des revues de code (ASVS)
• Pratiquer le “peer programming” avec un expert sécurité
• Se concentrer sur les besoins et ne pas faire de la sécurité pour faire de la sécurité
• Automatiser la sécurité progressivement en installant les outils qui vous conviennent

La culture du DevSecOps est avant tout une histoire d’humains.

Bug Bounty

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

Qu’est ce que le Bug Bounty

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 :

• Les programmes privés où quelques chercheurs (10 à 60) sont sélectionnés pour tester l’application. C’est le type de programme retenu par une organisation qui débute dans le bug bounty.
• Les programmes publics accessibles à tous les chercheurs inscrits sur la plateforme. Il permet de mettre à l’épreuve l’application face aux menaces réelles.
• Les programmes “OnSite” où les chercheurs sélectionnés sont réunis dans un même lieu pour tester la cible sur une semaine. Ce type de programme est privilégié pour tester des objets connectés ou lorsque la cible nécessite un haut niveau d’expertise.

Comment faire ?

Etape 1 : Créer son programme

Pour commencer, l’organisation doit définir les règles du jeux de son bug bounty :

• Cible
• Type de programme (Privé / Publique)
• Vulnérabilité recherchée
• Récompense

Etape 2 : Découverte d’une vulnérabilité

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 :

• Définir la priorité de traitement
• Accepter ou refuser la vulnérabilité (notamment si cela fait l’objet d’un doublon)
• Définir la gravité de la vulnérabilité

Etape 3: Remédiation

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.

Conclusion

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 !

Questions des participants

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