Loading...Suite à l’émergence de SCRUM, nous, les concepteurs de logiciels, sommes de plus en plus concentrés sur les pratiques agiles et sur les bénéfices qu’elles apportent aux utilisateurs finaux. Malgré tous les succès des projets agiles, ingénierie et agilité ont plus souvent des finalités opposées plutôt que complémentaires et les frameworks agiles n’apportent pas suffisamment de spécifications sur les pratiques de développement logiciel. Cette situation concerne entre autres les pratiques de sécurité. D’une manière générale et quelle que soit la méthodologie de développement, nous avons pu constaté lors des audits techniques que les critères liés à la sécurité et à la performance sont souvent négligés par les équipes de développeurs.
S’il est vrai que la notion de Definition Of Done doit être corrélée avec les besoins exprimés par le Product Owner, il est tout aussi vrai que le Product Owner a rarement une formation orientée sécurité applicative. Dans ce contexte, quel sera le minimum pour construire un produit d’un haut niveau de qualité dans ce domaine ?
Notre opinion, forgée par l’expérience est que la prise en compte de la sécurité doit se manifester dans chaque élément du projet Agile. L’architecture et le design du projet sont notamment les points critiques qui dictent le niveau de sécurité du projet. D’un point de vue opérationnel, les tâches liées à la sécurité ont une priorité plus élevée dans le backlog et ne sont pas les candidats à en être écartés lors des sprints difficiles.
Nous avons identifié 13 éléments importants à suivre concernant l’implémentation de la sécurité logicielle lors d’un projet agile de développement. Même si certains de ces éléments vont être développés par la suite dans des articles ultérieurs, nous avons voulu les synthétiser dans le schéma ci-dessous.
Le modèle de menaces
Ce document est un checklist avec les éléments de sécurité du projet et les attaques possibles et il est décliné dans les techniques PBI (Product Backlog Item) et dans la Definition Of Done. Cette étape d’intégration dans le Product Backlog est primordiale et évite la dispersion, sachant que par exemple en Scrum les Développeurs n’ont pas le droit de travailler sur autre chose que le Backlog. Ces PBI auront une priorités plus élevée.
Initialisation des tests automatiques
A ce stade-là, l’équipe doit choisir les outils potentiels pour l’automatisation des tests (sécurité, performance, de non-régression, d’intégration, de validation, unitaires ou de recette). Souvent, les équipes vont rajouter les décisions liées
aux tests automatiques lors des rétrospectives en fonction de l’avancement et du retour de chaque fin de sprint.
Il y a deux grandes catégories d’outils :
- Outils d’analyse du code : Ces outils produisent des rapports sur l’état courant du code. Certaines actions de la revue du code peuvent être remplacées par ces tests.
- Outils de test d’exécution : Ces outils exécutent des tests de sécurité sur l’application en exécution. Les tests « Fuzz » en sont de bons représentants. Ce type de tests consiste à fournir tout type de données (valides, inattendues, aléatoires) aux entrées de l’application. Pour des projets web il existe des outils spécialisés d’attaque. (Cross-Site Scripting ..)
Mise à jour des connaissances
L’itération reste au centre du projet Agile. C’est ici où le niveau des connaissance de l’équipe doit être garanti. Les nouveaux membres et ceux qui ont dépassé une certaine période d’intégration dans l’équipe vont suivre un cours sur les règles de sécurité pour le projet. Le rôle de la communauté de partage de connaissances est aussi essentiel car cette entité vit dans l’itération.
Analyse de la surface d’attaque
La surface d’attaque est représentée par tous les éléments techniques du projet qui viennent en contact avec les utilisateurs ou l’extérieur. C’est effectivement le point d’entrée de la plupart des attaques. L’équipe formalise la surface d’attaque dans des catégories et des priorités pour assurer un bon niveau de sécurité globale sur le projet.
Envie d’en savoir plus? Téléchargez le complément en PDF de cet article
Cet article a été rédigé par Irinel Matei, ex expert .Net Pentalog
Aymeric
octobre 8, 2012 à 02:42Article intéressant et sujet très vaste. La sécurité fait partie des sujets, pour les clients, où l’implicite est de rigueur alors que l’explicite est fondanmental. Comme tu l’as dit, il n’y a pas une sécurité mais des types de sécurité et à tous les niveaux de la chaîne de production logicielle, tout le monde doit prendre conscience de l’importance.
Le plus souvent, les priorités sont pilotées avec les exigences métiers et il peut être considéré comme anti-business d’insister de prioriser des taches relatives à la sécurité. Mais quand le malheur arrive les services sont indisponibles et l’image de marque est entachée … le business est touché en son coeur.
L’agilité est une méthode incontournable pour s’aligner au mieux avec business. La sécurité doit devenir une préoccupation à l’instar de l’ergonomie ou de la qualité des produits vendus.
Constantin Samoila
octobre 11, 2012 à 10:49Irinel, t’as présenté des bons points d’attention a faire par rapport a la sécurité des outils développés. La liste n’est pas complète, et dépend toujours de diffèrent facteurs impliqués (technologies, hébergement, accès, gestion..). Le temps alloués a la sécurité ne dois pas être au début ou a la fin du projet, mais pendant le développement, promouvoir dans l’équipe une culture de sécurité pareil comme une culture de qualité.
Maintenant pour mieux s’organiser a la gestion de la sécurité sur les projets, il faut s’en occuper, selon les normes l’ISO 9001 et 27001, de la gestion des risques (inc. risques de sécurité).
– dans un fichier/outil gérer la liste des actifs (IHM, BDD, Transactions App-BDD, Transactions Client-Serveur, IIS, Système, code source, fichiers, informations d’identification, accès, saisie ….) qui sont ouverts aux menaces de sécurité,
– évaluer les risques liés a ces actifs,
– établir des plans d’action pour les éliminer ou atténuer,
– définir des plans d’action pour ceux qui ne peuvent pas être éliminés,
– définir des niveaux d’acceptation pour les risques résiduels,
– après avoir estimé les charges nécessaires pour les plan d’actions, valider la cohérence, décider dans quel sprint et quel partie sera résolu.
Faire attention au fait que le processus de gestion des risques doit être itérative et en amélioration continue – il semble compatible avec Agile, non? 🙂
Cette organisation donne la possibilité de présenter au client a chaque étape du projet un plan d’action cohérent sur la gestion de la sécurité, l’importance, et le temps nécessaire pour le faire. Il est important de lui donner toujours la visibilité sur les 2 dimensions: qualité et sécurité. Il donne son accord, il accepte les conséquences et les dépenses a faire.