PDF-Download - Pentasys AG
Transcription
PDF-Download - Pentasys AG
Test de sécurité: une prévention pour vos applications Test de sécurité 06/2012 Ou: plus tard, ça sera plus cher L’importance du contrôle des systèmes d’information devient de plus en plus grande, si l’on regarde la quantité des applications web qui sont utilisées par des millions de gens sur Internet. Les pertes des grandes entreprises, dues aux vols de données, aux interruptions de service pour réparations et aux pertes d’image à la suite de violations de la sécurité et de défauts d’application se montent rapidement à plusieurs millions de dollar par an. Le test de sécurité permet de contrôler et de prouver qu’un système d’information répond bien aux exigences en matière de sécurité. Cet article décrit la façon dont le test de sécurité s’intègre dans le cycle de vie du logiciel et ce qu’il convient en général d’observer pour sa mise en œuvre dans l’entreprise. Des problèmes de sécurité peuvent apparaître dans un complexe d’application à différents niveaux. Les niveaux sont en règle générale répartis en interface utilisateur, application, système d’exploitation et réseau. Comme les failles sécuritaires les plus utilisées par les attaquants sont celles du niveau application, c’est lui qui sera au centre de nos observations. Par nature, les applications web sont particulièrement en danger (voir OWASP Top 10 Web Application Security Risks). Le test de sécurité permet de minimiser, voire d’éliminer les risques, avant même que les systèmes informatiques ne soient mis en ligne. Ces risques peuvent être les suivants, pour citer quelques exemples: Absence de vérification des paramètres de saisie (Unvalidate input) Contrôle d’accès insuffisant (Broken access control) Débordement de tampons (Buffer overflows) Erreurs d’injection (Injection flaws) Défauts d’authentification et de gestion de session (Broken authentication and session management) XSS (Cross site scripting) XST (Cross Site Tracing) Traitement erroné des erreurs par l’application web (Improper error handling) Stockage non sécurisé (Insecure storage) Déni de service (Denial of service) Gestion non sécurisée de la configuration (Insecure configuration management) TEST DE SECURITÉ dans le SDLC Il n’est pas rare que le logiciel ne soit testé que lorsque son cycle de vie a déjà atteint la phase du déploiement. En général il s’agit pourtant d’une pratique très inefficace et coûteuse. Une des meilleures méthodes pour empêcher l’apparition de failles sécuritaires dans les applications productives consiste à intégrer le critère sécurité dans chacune des phases du «Software Development Life Cycle» (SDLC). PENTASYS-Point de vue 06/2012 Les entreprises doivent par conséquent vérifier leur SDLC et assurer que la sécurité fasse partie intégrante du processus de développement. Ce n’est que si des tests de sécurité sont implémentés au cours du SDLC que le traitement adéquat de la sécurité peut être garanti, tout comme la surveillance efficace de l’ensemble du processus de développement. La recherche comme l’expérience acquise s’accordent pour affirmer l’importance pour les entreprises d’apporter une attention particulière au test de sécurité pendant les phases initiales du développement. Une sélection des principes du test de sécurité Securité Confidentiality (confidentialité) Integrity (intégrité) Availability (disponibilité) Privacy (vie privée) Authenticity (authenticité) Non-Repudiation (traçabilité) Access Control (contrôle d’accès) 2 PENTASYS-Point de vue 06/2012 Un scanner de sécurité ou un pare-feu d‘application peut, il est vrai, identifier les problèmes ou mettre en place des dispositifs de défense. Mais, en réalité, il n‘existe pas de solution miracle pour résoudre le problème du logiciel à la sécurité insuffisante. Il faut toujours avoir présent à l‘esprit que la sécurité est le résultat d‘un processus et non pas d‘un produit. Tester très tôt Lorsqu‘un défaut est découvert pendant une phase du début du SDLC, il peut être plus rapidement traité et corrigé à moindre coût. Les défauts sécuritaires ne diffèrent pas, sur ce plan, des défauts fonctionnels ou de performance. Dans ce cadre, un pas important consiste en ce que, comme l‘organisation de test, le développement soit mis au courant des problèmes de sécurité. Bien que de nouveaux outils et de nouveaux langages aident à développer de meilleurs programmes, de nouvelles menaces se font jour en permanence. C‘est pourquoi les développeurs doivent avoir présentes à l‘esprit lesquelles, parmi ces menaces, peuvent concerner le logiciel qu‘ils développent. Les formations sur le test de sécurité aident les développeurs à acquérir une mentalité leur permettant de tester les applications sous l‘angle de vue d‘un attaquant et d‘implémenter efficacement le test de sécurité pendant les phases initiales du SDLC. Connaître l’envergure sécuritaire nécessaire Avant d‘exécuter un projet, il est important de connaître l‘envergure que le sujet de la sécurité va y occuper. Il est donc indispensable d‘identifier tous les standards, les directives, etc. entrant en ligne de compte. Il peut s‘agir par exemple de directives européennes, de consignes nationales ou de consignes et standards propres à l‘organisation concernée. Les informations et les ressources devant être protégées doivent recevoir une classification indiquant la manière dont elles doivent être traitées (p. ex. confidentiel, secret, top secret). Développer une façon de penser adéquate Pour réussir à tester avec succès l’absence de faille de sécurité dans une application, un mode de pensée «out of the box» est indispensable. Souvent, c’est le comportement «normal» d’une application qui est au centre du test de celle-ci. Pour pouvoir détecter les failles de sécurité, les tests doivent aller plus loin et être effectués sous l’angle de vue d’un attaquant. Une bonne dose de créativité peut alors aider à déterminer comment une application, confrontée à des données inattendues, peut déraper vers un problème sécuritaire. Il peut aussi être utile d’identifier certaines hypothèses des développeurs qui peuvent s’avérer inexactes et risquent ainsi d’être contournées. C’est d’ailleurs une des raisons qui font que les outils automatisés ne puissent pas déceler toutes les failles de sécurité. La pensée créative doit être mise en œuvre au cas par cas, car la plupart des applications web sont développées de façon très individuelle (même si des Frameworks courants sont utilisés). Utiliser les bons outils Comme nous l’avons déjà constaté, aucun outil ne représente la solution miracle pour le test de sécurité. Ce qui n’empêche pas les outils de jouer un rôle important. Il existe ainsi toute une série d’outils commerciaux et Open Source capables d’automatiser de nombreuses activités de routine du test de sécurité. Ces outils peuvent simplifier et accélérer le processus de test en aidant le testeur sécuritaire dans son travail. Il est toutefois important de comprendre de quoi ces outils sont capables et ce qu’ils ne peuvent pas faire. C’est la seule manière d’assurer qu’ils ne soient ni surestimés, ni utilisés de manière incorrecte. Un test positif exécuté au moyen d’un outil ne signifie pas que le logiciel développé soit bon. Quelques études ont montré que les outils ne détectent, dans le meilleur des cas, que 45 % des points faibles. Quelles sont les techniques qui sont utilisées ? Différentes techniques sont utilisées dans le cadre du test de sécurité, et spécialement ici en ce qui concerne les applications web: Inspections et examens, Threat Modeling, Examen du Code, Test de pénétration. Les techniques ne peuvent pas être décrites une par une, avec leurs avantages et leurs inconvénients, dans cet article pour des raisons de place: voir à ce sujet «OWASP Testing Guide». Étant donné les différentes techniques et approches pour le test de la sécurité des applications web, on peut se poser la question de savoir lesquelles d’entre elles doivent être employées et à quel moment. L’expérience montre qu’il n’y a pas de bonne ou de mauvaise réponse à cette question lorsqu’il s’agit d’élaborer un cadre de test. Souvent, c’est l’intégralité des techniques qui doit être mise en œuvre afin d’assurer que tous les secteurs concernés par le test soient effectivement testés. Il est toutefois bien clair qu’il n’existe aucune technique permettant à elle toute seule de couvrir tous les tests de sécurité à effectuer. Dans la pratique; beaucoup d’entreprises ont, jusqu’à présent, mis en œuvre le test de pénétration. Il a sa place, mais n’est pas capable de détecter tous les problèmes et ne suffit donc pas. De plus il intervient trop tard dans le SDLC. Une approche appropriée doit donc être équilibrée, inclure les différentes techniques et être ainsi en mesure de couvrir le SDLC complet. C’est ainsi que les illustrations ci-contre représentent les répartitions des efforts de test par phase de SDLC et pour la part respective des techniques. Définition Design Déploiement Développement Maintenance examen du processus et inspection manuelle examen du code Test de pénétration COMPÉTENCES NECESSAIRES POUR LE TEST DE SECURITE Pour l’exécution de tests système intégrés, les testeurs sécuritaires ont avant tout besoin de connaissances concernant les points faibles des systèmes (particulièrement pour les applications web) et les techniques de test Black-Box et White-Box pour le domaine du test de sécurité. Les exemples suivants peuvent illustrer la profondeur que ces connaissances doivent avoir: Pour le test de pénétration, un testeur a besoin de connaissances étendues sur TCP/IP, les réseaux et les systèmes d’exploitation, de connaissances élargies sur les points faibles des réseaux et les systèmes et sur la manière d’en tirer profit. Pour un examen de la configuration système, un testeur doit connaître les configurations système sécurisées, y compris le durcissement de systèmes d’exploitation, et les standards sécuritaires pour la configuration d’un grand nombre de systèmes d’exploitation. De plus, le testeur sécuritaire doit bien comprendre le processus de test et les normes de sécurité impliquées être en mesure de sélectionner les outils sécuritaires les mieux à même de supporter le test, savoir comment mettre en œuvre ces outils. PENTASYS-Point de vue 06/2012 3 Test de sécurité 06/2012 C’est pourquoi l’expérience acquise par un testeur dans le domaine du test de sécurité a tellement d’importance. Plus il connaît les méthodes de test et les outils avec précision par la pratique, meilleurs seront les résultats des tests et des analyses sécuritaires. C’est pourquoi, dans ce domaine, les investissements ne doivent pas se limiter aux outils, mais se refléter également dans la qualification et la formation du personnel. DIRECTIVES POUR LE TEST DE SECURITE Un grand nombre de directives existent pour le test de sécurité. Elles peuvent servir d’outils pour la planification, la préparation et l’exécution des tests. Deux directives ou ensembles de directives sont brièvement présentés ci-après. Open Source Security Testing Methodology Manual Le «Open Source Security Testing Methodology Manual» (OSSTMM) a été développé par l’ISECOM ou «Institute for Security and Open Methodologies» et représente le standard pour les tests de sécurité. L’OSSTMM contient un ensemble de consignes allant jusqu’aux «tasks» individuelles nécessaires à l’exécution de tests de sécurité. Le «Risk Assessment Value» met à disposition un ICP (indicateur clé de performance) ou KPI avec lequel la sécurité opérationnelle peut être mesurée et représentée. Une métrique clairement définie permet dans tous les cas une meilleure comparabilité des résultats ainsi qu’un meilleur contrôle de la réussite des mesures sécuritaires mises en œuvre. Les «Rules of Engagement» constituent un autre élément central. Elles contiennent les consignes éthiques et légales faisant foi pour toutes les personnes certifiées OSSTMM et tous les tests exécutés selon l’OSSTMM. Les «Rules of Engagement» reflètent une attitude de base positive et constructive vis-à-vis de la sécurité. L’utilisation de FUD (fear, uncertainty and doubt) à des fins de marketing est interdite. Contrairement aux standards ISO/IEC usuels, l’OSSTMM se place en tant qu’instruction concrète indiquant ce qui doit être testé et documenté, et de quelle manière, sans pour autant imposer l’utilisation d’outils concrets. En ce qui concerne les audits sécuritaires, l’OSSTMM 3.0 est compatible avec les standards usuels tels que ISO/IEC 27001/27002, Catalogues de protection de base IT, SOX et Bâle II. Open Web Application Security Project Guides L’OWASP (Open Web Application Security Project) représente une organisation d’experts pour la sécurité des applications web qui a été fondée en 2001 en tant que communauté Internet. La communauté est ouverte à toutes les personnes intéressées par la sécurité informatique pour les applications web. L’OWASP met à disposition un ensemble d’informations, de programmes, de consignes et d’instructions au sujet de la sécurité des applications web, entre autres l’OWASP Testing Guide, le Code Review Guide et le Development Guide. L’auteur de l’article Marc Mühlhans totalise de longues années d’expérience pratique dans le domaine de l’assurance qualité logicielle. Il a pris une part importante au développement des services d’assurance qualité (QAS) de PENTASYS et mis en pratique avec succès un grand nombre des prestations qui y sont définies. Point de vue – Le magazine consacré à l’informatique est une newsletter gratuite de PENTASYS AG. PENTASYS AG fait partie des intégrateurs de systèmes informatiques qui connaissent la croissance la plus rapide. Fondée en 1995, Pentasys emploie aujourd’hui 350 professionels de l’informatique en Allemagne. La stratégie de l’entreprise se concentre sur une qualité sans compromis, en se focalisant strictement sur la valeur ajoutée générée pour les clients. Des collaborateurs hautement qualifiés et très motivés, et un modèle de processus projet, certifié selon la norme ISO-9001/2008 forment les conditions de réussite de cette stratégie. La palette de ses prestations regroupe le conseil, la gestion de projet, l’analyse de la faisabilité, la conception d’architecture, la réalisation et le test de systèmes IT, le tout piloté par un interlocuteur unique. Le contenu, la conception et le design, sont protégés par un copyright. Le copyright et le droit de la propriété intellectuelle sont détenus par PENTASYS AG. PENTASYS AG Bureau de Paris 1, passage du Génie F-75012 Paris Tél. : + 33 (0)1 76 36 02 90 [email protected] www.pentasys.de www.pentasys.fr www.pentasys.co.uk © 2013 PENTASYS AG. PENTASYS AG Rüdesheimer Straße 9 D-80686 Munich Tél. : + 49 (0) 89 5 79 52-0