Rechercher
Contactez-nous Suivez-nous sur Twitter En francais English Language
 











Abonnez-vous gratuitement à notre NEWSLETTER

Newsletter FR

Newsletter EN

Vulnérabilités

Se désabonner

Conférence du CLUSIF - Développement agile : la sécurité doit aussi se rendre agile

juin 2019 par Marc Jacob

Dans le cadre de la Paris Cyber Week, le CLUSIF a organisé une conférence dont le thème était « Pour des organisations performantes : associer confiance numérique et informatique agile. Plusieurs RSSI ont témoigné sur la manière d’intégrer la sécurité dans les projets de développement agile. Il est clair que ces méthodes demandent un changement dans la manière de penser le développement et d’y intégrer la sécurité. Le maître mot reste l’agilité tant dans les architecteurs et les services développés que dans la manière de penser la sécurité.

En préambule Thierry Chiofalo, administrateur du CLUSIF a expliqué que l’informatique agile passe aujourd’hui par DevOps. Cette manière de développer permet d’aller beaucoup plus vite par contre, elle ouvre de nouvelles vulnérabilités.

Sébastien Dupont, un RSSI, a présenté comment « planter son projet agile... en 8 points ». Pour lui le début du problème réside dans le fait qu’il faut implémenter des mesures de sécurité à la fois techniques et organisationnelles avec entre autre le RGPD et en particulier l’article 32. Le premier piège est le sponsor du DG qui au départ est très intéressé. Toutefois avec le temps, il s’éloigne du projet et commence à demander un ROI de la sécurité... le deuxième piège est de ne pas être familier avec l’ANSSI et le CLUSIF, la CNIL, le NIST, l’OWASP qui publient régulièrement des guides. Pourtant, ces derniers sont très utiles et doivent être mis en pratiques. Le troisième piège est souvent « d’être trop bon élève en analyse de risques » et donc de sous-estimer les budgets. De ce fait, il ne faut pas viser la perfection mais plutôt faire de la conformité. Le second problème dans l’analyse de risque reste de vouloir réinventer « la poudre » alors que des guides sont déjà publiés. De ce fait, il conseille de les utiliser.

Le quatrième écueil à éviter est de pas abuser du pouvoir de « maîtriser les risques » qui l’incite à refuser des évolutions du SI. Les RSSI doivent plutôt se référer au guide de « la commission d’homologation » qui permet d’émettre plus facilement des avis de sécurité favorables ou défavorables ou des réserves. Il faut aussi avoir un état d’esprit de services et de réactivité.

Le 5ème point pour planter un projet est de ne pas scorer le By Design. En effet, le scoring permet d’avoir des indicateurs simples et de viser une amélioration minimum tous les mois. Pour cela il faut définir un modèle comme par exemple de prendre des indicateurs simples et bien sûr d’avoir un processus de PDCA.

Le sixième point est de ne pas nommer des chefs de projets ou d’avoir des chefs de projets dans « des silos ». Il faut au contraire qu’ils aient un catalogue de services de sécurité.

Le septième point est de ne pas jouer en équipe. Il faut au contraire mettre en place des groupes de travail, des commissions. Pour créer des équipes, il conseille de se référer au guide de l’ANSSI des métiers de la sécurité et du guide de la CNIL sur l’analyse d’impact à la protection des données et travailler donc avec les DPO.

Enfin, pour ne pas planter un projet, il faut bien définir les rôles de chacun. Il est nécessaire pour cela se référer au guide d’homologation. Enfin, il faut développer un guide d’éthique du numérique afin de savoir et pouvoir dire non pour éviter les dérives.

L’analyse de risque lors de développement agile par l’ANSSI

Vincent Desroches de l’ANSSI a présenté la guide l’ANSSI « sécurité numérique » qui permet de réaliser une analyse de risque lors de développement agile. Pour introduire sa présentation, il a donné plusieurs exemples d’attaques avérées. Selon lui, les attaquants ont une démarche agile pour procéder à leurs méfaits. Les grandes tendances pour les pirates sont les ransomwares, l’espionnage, le vol de données...

L’analyse de risque en mode agile est très difficile. Ainsi, ce guide permet de mettre de la sécurité dans les méthodes de développement en mode agile. Il faut conduire les équipes de développement. En conclusion, il estime qu’un atelier ne doit pas être inférieur à 30mn et ne pas dépasser 2h.

Développement agile et sécurité : pas de contre-indication dans les faits

Le débat entre des RSSI animé par Lumena Duluc a permis de montré que méthode agile et sécurité ne font sur le terrain au début pas très bon ménage même si il n’y a pas de réticence. La sécurité amène plus de rigueur aux petits groupes de travail qui n’ont pas une vision globale des produits à développer mais une approche sous forme de microservices. Chez Dailymotion, une analyse de risques de haut niveau a été réalisé rapporte Quentin Berdugo. A côté, de cela de l’éducation auprès des développeurs a été entreprise pour qu’ils se coordonnent avec la SSI lors de développements majeurs ou la création d’architectures à risques. Des tests automatisés sont aussi pratiqués afin de déterminer les vulnérabilités, les ports ouverts, les images dockers, les configurations AWS... De plus, sa société fait des Bug Bounty privés et publics. Thomas Faure de Whaller, un réseau social sécurisé utilise, pour sa part, régulièrement lui aussi le Bug Bounty depuis le jour où un « white Hacker » l’a contacté en lui montrant qu’il avait une centaine de vulnérabilités sur son site.

Abri Mouakher d’Engie Digitale qui a été créée pour fournir des services aux entités du groupe en intégrant directement la sécurité. Pour elle, une analyse de risque doit se faire le plus rapidement possible. Ainsi, ils ont automatisé cette analyse et a intégré de l’analyse de code à chaque étapes de développement. L’objectif est de rendre la sécurité un automatisme aux équipes de développement en ayant une vision d’acceptation des erreurs pour ne plus refaire le même. Les équipes, en outre, essaient d’avoir une approche attaquant. Elle considère le RGPD les a beaucoup aidé dans leur démarche. Elle estime qu’il faut repérer dans les équipes de développement son allié qui est la personne la plus sensibilisée à la sécurité. Elle conseille d’organiser des réunions de 30 minutes toutes les semaines avec les développeurs pour éviter de se mettre en mode projets qui sont lourds à gérer, coûtent chers et surtout ne sont pas adaptés au mode de développement agile.

Jérémy Renard, de Capgemini Invent considère que la démarche agile est une nouvelle méthode de développement qui va bien plus vite et raccourcie de plusieurs années à quelques mois la mise en production. Les clés du succès sont :
 Le côté humain et organisationnel.
 La méthodologie.
 Enfin la technologie avec ses outils d’automatisation et d’anticipation. En effet, il existe des outils pour automatiser les déploiements, vérifier les codes,..

Afin de convaincre les métiers, il a organisé un séminaire avec des DSI, des responsables de services... pour leur montrer les gains de temps qui sont aujourd’hui nécessaires. Une fois, qu’un premier projet a réussi toutes les équipes veulent faire de même.

Quentin Berdugo rappelle qu’il ne faut pas être dogmatique. Par exemple, il est nécessaire de penser à automatiser la sécurité. Par contre, il faut parfois dire non sur l’urbanisme du SI afin de réduire les périmètres. De son côté, Jérémy Renard conseille de prévoir des temps en amont pour anticiper la sécurité. Il faut aussi avoir un plan B explique-t-il. Abderrahmane Smimite d’Intuitem ajoute pour conclure qu’il faut savoir apprécier les risques résiduels.


Voir les articles précédents

    

Voir les articles suivants