Éclairer le futur est notre métier

Taille du texte: +

Compte-rendu de la Matinale : DevSecOps League

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 du petit déjeuner sur SlideShare. La vidéo du petit-déjeuner 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 “peer 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 :

 

Type Usage Exemple Phase
Auteur d'origine: Anne Sophie Varnier
Ouverture d'un nouveau centre de recherche en inte...
La sidechain « Liquid » enfin ouverte aux transact...
 

Commentaires

Pas encore de commentaire
Already Registered? Login Here
Guest
dimanche 18 novembre 2018

Image Captcha

Copyright © 2018 SLA
167 Chemin des Combes 74110 Essert-Romand - tel : 04.50.83.06.79 - Mobile : 06.75.23.84.11

Mentions légales    -    Politique de confidentialité    -    Plan du site

IMPORTANT

copyright

 Notre blog est un blog de Curation, aussi les articles publiés proviennent-ils de différents flux RSS et nous ne prétendons, en aucune manière, nous en attribuer la paternité. Si vous souhaitez lire l'article original sur le site d'origine, il vous suffit de cliquer sur "Lien d'origine " qu se trouve à la fin de l'article.

Traduire

frendeitptrues

Rechercher

CES 2018

Un CES qui fait whoa !

Regard sur le CES 2018

Témoignages

Ils ont assisté à nos séminaires et ils donnent leurs avis.

Ce que les participants en pensent

Programme 2018 - 2019

Aller au haut