Accueil Nos publications Blog Cycle de vie d’un projet – Et si on parlait sécurité?
Non classé
13/07/2010 5 min

Cycle de vie d’un projet – Et si on parlait sécurité?


Les applications professionnelles font -de plus en plus- appels aux technologies Web. Ces technologies offrent une panoplie d’outils très variés et qui tendent à simplifier l’intégration des solutions et donc les rendre accessibles pour leurs clients, leurs partenaires ou toute autre population. Cependant cette facilité peut être synonyme de vulnérabilité : Le fait d’exposer son système peut induire à des utilisations malveillantes (vols de données, intrusion, …) et provoquer d’énormes pertes parfois irréversibles.
Face à ce risque, il existe bien des solutions. Ces solutions peuvent être matérielles et/ou applicatives et relèvent généralement -et là je vais vous étonner- de bonnes pratiques. Eh oui, la sécurité n’en sera pas épargnée.

Etat des lieux

La gestion de projet mesure forcément l’importance de l’aspect “sécurité” mais n’arrive que rarement à le formaliser de manière claire et précise au sein des processus internes et plus particulièrement ceux liés aux cycles de vie des projets. Cet aspect est souvent relégué aux dernières étapes des projets voire assuré par les équipes de production qui gèrent surtout l’aspect infrastructure (firewall, détecteur d’intrusion, …) inefficace contre les failles applicatives plus faciles à découvrir et à exploiter.
Pour produire une solution sécurisée, il est impératif de connaître les risques et de mesurer leurs impacts afin de mieux les contrer. Voici donc une petite piqûre de rappel!

Les failles de sécurité


Les failles applicatives les plus couramment exploitées sont les suivantes :

  • Les injections.
  • L’usurpation des paramètres d’authentification.
  • La fuite d’information

Vous pouvez consulter ici un classement exhaustif des risques pour 2010 sur le site de l’Open Web Application Security Project (OWASP).
Je ne développerai donc pas chacune des failles précédemment citées, mais afin de mieux prendre conscience des risques liés aux différents types d’attaques quoi de mieux que la pratique! Je vous propose donc de jouer aux apprentis pirates avec l’application Jarlsberg made in Google. En quelques mots, Jarlsberg est une application affichant de multiples défaillances destinées à être exploitées. Un index liste l’ensemble des failles existantes et décrit les manières de les exploiter.

La sécurité par le management

Vous avez forcément entendu parler du CMMI avec ses 5 niveaux, ses critères et ses bonnes pratiques nécessaires à améliorer la qualité des processus (les fameuses constellations). Ce que je vous propose donc, c’est encore de bonnes pratiques, mais dans le domaine de la sécurité.
Il existe une multitude de modèles de gestion de la sécurité, dont les descriptions convergent vers un unique but : intégrer la réflexion sur la problématique de la sécurité depuis l’analyse des besoins jusqu’à la livraison du produit fini. Le problème est que ces pratiques ne sont courantes que chez les spécialistes de la sécurité qui interviennent généralement pour des audits en fin de projet, et ces mêmes pratiques tardent à être adoptées par les équipes de MOA, MOE et même par les équipes de développement.
Pour mettre un terme à ce manquement, je vous propose une petite présentation du framework SAMM que j’ai découvert récemment, et qui permet d’introduire l’étude de la sécurité avant, pendant et après le projet.
Comme toute bonne présentation, je vous propose de commencer par une définition : Le Software Assurance Maturity Model est un framework de sécurité qui spécifie les ressources nécessaires pour définir et implémenter une stratégie de sécurité. Ce volet s’intéresse à toutes les phases du projet et s’inscrit dans le métier de management. SAMM offre une solution flexible et complètement indépendante du style de développement afin de garantir une compatibilité avec toutes les structures organisationnelles.

Les principes de SAMM

  • Evolution en petite itération afin de suivre le cycle de la solution.
  • Adaptation aux besoins réels de tolérance de risque.
  • Chiffrage des objectifs (feuille de route).
  • Tests et mesures de conformités.

Le modèle de SAMM se base sur le métier du développement logiciel et fournit un ensemble de bonnes pratiques de sécurité pour chaque fonction du métier. L’ensemble de ces pratiques permettent aux entreprises de réduire les risques et de s’engager sur la qualité de leurs solutions en matière de sécurité. Voici une vue générale du modèle de sécurité de SAMM.
Figure_1 : Modèle de SAMM
La fonction de pilotage (Governance) s’intéresse à l’organisation du développement logiciel et implique donc toutes les équipes qui participent de près ou de loin à la réalisation. Le pilotage invite à la mise en place d’une stratégie de sécurité, à compléter celle-ci par des outils de gestion et de mesure et enfin à former et à sensibiliser les effectifs aux principes de sécurité.
La phase de construction, quant à elle, invite à intégrer les pratiques de sécurité lors de la spécification des besoins et de la conception. Au cours de cette phase, il faudra définir les risques auxquels le produit sera exposé, établir la liste des moyens nécessaires à la protection aux niveaux applicatif et matériel.
Ensuite, la phase de vérification décrit l’ensemble des activités à mener pour s’assurer du niveau de sécurité du logiciel; tel que la revue de code ou la définition de planning de tests.
Enfin, la phase de déploiement clôture l’ensemble des tâches précédentes et assure un suivi de la sécurité de la solution en production. Cette étape correspond à un monitoring de sécurité.

Pour plus d’information concernant le framework SAMM je vous invite à lire la documentation officielle (dans sa version 1.0). Dans cette même documentation, vous pouvez consulter une étude de cas qui illustre l’utilisation du framework SAMM (page 82).

Conclusion

L’objectif de cet article est de sensibiliser les intervenants, sur les projets d’entreprises, aux problématiques liées à la sécurité. Ces problématiques demeureront un challenge face à l’évolution et la complexification continue des technologies qui sont susceptibles de produire de nouveaux types de vulnérabilités.
Du point de vue méthodologie, il est à savoir que SAMM n’est pas le seul framework de bonnes pratiques de sécurité, il existe d’autres framework tel que le SDL Optimization model ou le Building Security in Maturity Model qui prend même ses racine dans une version antérieure de SAMM.

Figures

  • Figure_1 – https://www.owasp.org/index.php/SAMM#tab=Main

Références

Rédigé par :

Haythem ZAYANI