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