Les méthodes AGILES et la CyberSécurité
C'est vrai, je n'ai pas essayé. Mais je suis persuadé que si vous essayiez de courir avec une armure, vous arriveriez à la même conclusion que moi : c'est difficile et épuisant. Garder un niveau de cyberdéfense quand on est en méthode SCRUM ou pire en méthode AGILE, c'est un vrai challenge. Avec une livraison toutes les une à trois semaines, comment trouver le temps de se prémunir contre les vulnérabilités potentielles ? D'autant que culturellement, la sécurité est basée sur du solide, du permanent. Assurer la sécurité, c'est garantir la pérennité d'un processus, la continuité de l'activité.
Dans les règles qui régissent les méthodes agiles, beaucoup pourraient être complètement antinomiques avec la sécurité. Dans l'esprit d'un développeur agile, il faut livrer des versions opérationnelles le plus souvent possible : Dès que ça marche on livre, c'est ce que le client voit et exige. Sauf qu'on oublie le mot opérationnel. A l'heure d'attaques permanentes contre tous les systèmes informatiques, peut-on considérer que le logiciel mis en production est "opérationnel", dès lors qu'il menace l'ensemble du système informatique du client, et ses utilisateurs ? Il faut aussi mesurer les impacts des décisions qui sont prises : est-il pertinent de publier une nouvelle version qui va augmenter les fonctionnalités, mais peut être permettre à des concurrents de voler du savoir-faire, ou à des hackers de bloquer la production de l'entreprise grâce à des ransomware.
Autre exemple parmi les règles de méthodes agiles : Mesurer l'avancement du projet en termes de fonctionnalités. Mais quel développeur sérieux n'inclurait pas les fonctionnalités de sécurité dans les spécifications : Identification des utilisateurs, authentification, contrôles d'accès, etc... L'excellence de la conception ne peut pas se passer de prévoir dans les développements ce qui doit permettre de se défendre.
Pour accélérer les développements, 99,5% les développeurs utilisent de l'Open Source. Sur les 10 dernières années, plus des deux tiers du code utilisé sont issus de l'Open Source. Ce qui crée également des vulnérabilités : 80% des vulnérabilités exploitables proviennent de l'implémentation logicielle.
Les méthodes agiles prévoient d'automatiser des tests. Pourquoi dès lors ne pas prévoir la mise en oeuvre de tests de sécurité (Security Testing) ? Le mode SAAS (Software As A Service) est particulièrement adapté à ce type de test, et les outils tels que HP Fortify On Demand ou l'offre de test sur l'Open Source BlackDuck (pour ne nommer que ceux là), existent.
Ces outils ne sont pas suffisants en eux-mêmes, et les pentesters les plus efficaces ne les utilisent que marginalement pour les évaluations les plus pointues. Mais même si ce n'est pas l'arme absolue, ces outils restent cependant efficaces pour se protéger de la très grande majorité des vulnérabilités publiées. Ils ne fonctionnent pas tout seuls, et il est nécessaire d'intégrer dans l'équipe de développement un ou plusieurs pentesters ou ingénieur R&D en CyberSécurité pour regarder les résultats de ces outils, et faire corriger les vulnérabilités identifiées avant de considérer la livraison comme opérationnelle.
Soyez donc vigilants à observer un équilibre entre les avantages des développements agiles et la sécurisation nécessaire de vos applications.
CPTO Frandroid / Numerama / Madmoizelle
7 ansVia les méthodes agiles, on peux délivrer en continue et s'assurer que les librairies open source utilisées sont à jour. Ainsi on réduit drastiquement les failles connues et exploitables facilement (recherchées et testées automatiquement via des robots par exemple). Il n'y a rien de pire que du code open source non mis à jour depuis 5 ans pour lequel quantités de failles ont été publiées. Dans cette optique, les méthodes agiles peuvent être un sacré allié. ça impose au attaquant plus de recherches "manuelles" pour trouver des failles. L'automatisation des tests est également indispensable car il est tout à fait possible de tester unitairement le code pour s'assurer qu'il n'y ai pas de régression de sécurité. Par exemple : mise en place de tests unitaires pour vérifier que les informations sensibles ne se retrouvent pas exposées (dans les caches, dans les logs, dans des retours de réponses d'API, etc.).