Le cadre de test de sécurité Web

Aperçu

Cette section décrit un cadre de test typique qui peut être développé au sein d'une organisation. Il peut être considéré comme un cadre de référence composé de techniques et de tâches appropriées aux différentes phases du cycle de vie du développement logiciel (SDLC). Les entreprises et les équipes de projet peuvent utiliser ce modèle pour développer leur propre cadre de test et pour définir la portée des services de test des fournisseurs. Ce cadre ne doit pas être considéré comme prescriptif, mais comme une approche flexible qui peut être étendue et adaptée pour s'adapter au processus de développement et à la culture d'une organisation.

Cette section vise à aider les organisations à construire un processus de test stratégique complet, et ne s'adresse pas aux consultants ou aux sous-traitants qui ont tendance à être engagés dans des domaines de test plus tactiques et spécifiques.

Il est essentiel de comprendre pourquoi la construction d'un cadre de test de bout en bout est cruciale pour évaluer et améliorer la sécurité des logiciels. Dans Writing Secure Code, Howard et LeBlanc notent que la publication d'un bulletin de sécurité coûte à Microsoft au moins 100 000 $, et qu'il en coûte collectivement à leurs clients beaucoup plus que cela pour mettre en oeuvre les correctifs de sécurité. Ils notent également que le site web CyberCrime du gouvernement américain détaille les affaires criminelles récentes et les pertes pour les organisations. Les pertes typiques dépassent largement 100 000 USD.

Avec de telles données économiques, il n'est pas étonnant que les fournisseurs de logiciels passent de la seule exécution de tests de sécurité en boîte noire, qui ne peuvent être effectués que sur des applications qui ont déjà été développées, à la concentration sur les tests dans les premiers cycles de développement d'applications, tels que pendant la définition, la conception et le développement.

De nombreux professionnels de la sécurité considèrent encore les tests de sécurité comme relevant du domaine des tests de pénétration. Comme indiqué dans le chapitre précédent, bien que les tests de pénétration aient un rôle à jouer, ils sont généralement inefficaces pour trouver les bogues et reposent excessivement sur les compétences du testeur. Ils ne doivent être considérés que comme une technique de mise en oeuvre ou pour sensibiliser aux problèmes de production. Pour améliorer la sécurité des applications, la qualité de la sécurité du logiciel doit être améliorée. Cela signifie tester la sécurité pendant les étapes de définition, de conception, de développement, de déploiement et de maintenance, et ne pas s'appuyer sur la stratégie coûteuse d'attendre que le code soit complètement construit.

Comme indiqué dans l'introduction de ce document, il existe de nombreuses méthodologies de développement, telles que le Rational Unified Process, le développement eXtreme et Agile, et les méthodologies traditionnelles en cascade. L'objectif de ce guide n'est ni de suggérer une méthodologie de développement particulière, ni de fournir des conseils spécifiques qui adhèrent à une méthodologie particulière. Au lieu de cela, nous présentons un modèle de développement générique, et le lecteur doit le suivre en fonction du processus de son entreprise.

Ce cadre de test comprend des activités qui doivent avoir lieu :

• Avant le début du développement,
• Pendant la définition et la conception,
• Pendant le développement,
• Pendant le déploiement, et
• Pendant la maintenance et les opérations.