Sécurité du code et des données

Ressources

Comment choisir une solution de test de sécurité des applications

January 13, 2014

Tiny Url for this post: http://tinyurl.com/p5v27ah

1. Introduction

Acquérir une solution de test de sécurité des applications, est actuellement une question inscrite à l’ordre du jour de nombreuses organisations. Leurs motivations peuvent être différentes (première introduction de la sécurité dans le SDLC, besoin d’améliorer leurs outils existants,…) mais toutes sont unanimes à reconnaître qu’un outil de gestion de la sécurité des applications doit faire partie intégrante du SDLC, et pouvoir être utilisé par tous les acteurs du cycle de développement (développeurs, QA, DevOps).

Forts de notre expérience comme conseil auprès de nombreuses organisations, pour la construction de programmes de développement sécurisés,  nous avons dressé une liste des principaux critères à prendre en compte au moment du choix d’une solution de test de sécurité applicative.

De cette liste, trois caractéristiques dominantes se dégagent : la Précision, la Clarté, et la Simplicité, qui devront s’accorder au mieux avec un quatrième critère : les Objectifs Métiers.

2. Critères à considérer

2.1 Précision :

Réduction des faux négatifs – Détection exclusive des failles réelles

Les faux négatifs sont des vulnérabilités réelles qui n’ont pas été détectées.

Les faux négatifs peuvent provenir de multiples sources : prise en charge insuffisante de l’application (non entièrement testée), test défectueux (le test effectué a été incapable d’identifier la vulnérabilité), ou encore absence de test (certaines vulnérabilités ne sont mêmes pas testées). Quelle qu’en soit la cause, les faux négatifs représentent un véritable risque pour l’entreprise.

Elimination des faux positifs

Les faux positifs sont de fausses vulnérabilités mais détectées comme étant réelles, et dont l’élimination est nécessaire.

En effet, une solution qui n’élimine pas les faux positifs oblige l’entreprise à faire appel un personnel spécialisé,  pour effectuer ce tri entre les vraies et les fausses vulnérabilités. Cette opération coûteuse tant en matière de finance que de  temps, est préjudiciable notamment aux environnements Agile où les délais de livraison sont extrêmement serrés.

Par ailleurs, la présence de faux positifs dans les résultats nuit au climat de confiance, nécessaire à un bon fonctionnement du SDLC, entre les équipes de sécurité et celles de développement. Des développeurs à qui l’on demande de consacrer du temps à analyser et corriger des failles qui,  en réalité, n’en sont pas, finiront légitimement par douter du sérieux de leurs collègues de la sécurité ainsi que de leurs outils aux résultats si peu fiables.

Afin d’obtenir une sécurisation optimale de ses applications, l’entreprise doit tout mettre en œuvre pour que s’instaure un climat de cohésion entre les différents acteurs du cycle de développement. Le choix d’une solution de test de sécurité participe de cette mise en œuvre.

Couverture maximale du code

Les applications modernes disposent de nombreux composants et bibliothèques provenant de différentes sources (composants développés préalablement en interne, bibliothèques open source, cadres communs de développement etc…). Toutes ces sources contiennent potentiellement des failles. C’est pourquoi il est important que la totalité du code contenu dans l’ensemble des couches de l’application,  soit correctement testée, y compris le code généré automatiquement, le code généré à la volée, les composants pour lesquels le code source n’est pas disponible etc… Un autre paramètre à prendre en compte concernant la couverture des applications,  est la capacité à détecter les vulnérabilités qui se situent à différents endroits de l’application, comme faisant partie d’une transaction unique.

Rapidité de fonctionnement, indispensable à Agile

L’un des objectifs sous-jacent à l‘utilisation d’une solution automatisée de test de sécurité est de pouvoir tester les applications en continu, dans le cadre du processus de développement. Dans les environnements Agile et d’intégration continue, le code est fréquemment modifié, ce qui oblige l’outil de test de sécurité à faire preuve d’une efficacité extrême pour répondre aux exigences de délais particulièrement serrés. Il n’est pas question que le test de sécurité de l’application se transforme en goulet d’étranglement, la livraison de cette dernière ne pouvant être retardée pour cause de vérification des performances de sécurité.

 

2.2 Clarté

 

Lecture limpide des résultats 

Visualiser et comprendre les résultats pour ceux qui ne sont pas experts du domaine de la sécurité est impératif pour hiérarchiser et corriger les failles détectées. Afin de l’intégrer au SDLC, le personnel non spécialiste de la sécurité devra être capable de faire fonctionner la solution à une fréquence régulière. Il s’agit principalement de développeurs, de personnes  du QA, ou d’ingénieurs DevOps. La solution doit livrer des résultats non seulement clairs et compréhensibles, mais également documentés de toutes les informations pertinentes concernant les risques encourus par l’application.

Mise en œuvre d’une gestion des vulnérabilités et d’un plan de correction

Un outil de sécurité, doit être capable, après avoir analysé l’application web, de faire un rapport des vulnérabilités qu’il aura détectées, de localiser l’emplacement du code où la vulnérabilité prend sa source, et  de suggérer les différentes étapes à entreprendre pour la corriger. De plus, il doit fournir les informations détaillées et complètes permettant de documenter chaque vulnérabilité détectée.

Ces exigences sont requises depuis que les tests de sécurité des applications ont été intégrés à la gestion du risque, et que les vulnérabilités identifiées sont devenues une priorité en termes d’urgence de correction. Une bonne solution de tests de sécurité des applications devra contribuer à mettre en place ce processus en fournissant des résultats à partir desquels il sera possible de visualiser à la fois le risque et les corrections adéquates.

Lecture des résultats accessible aux différents acteurs de l’entreprise

La visibilité est un critère majeur, indispensable aux différents acteurs de l’organisation. Qu’ils soient chefs d’entreprise, directeurs produit, ou chefs de projets, tous sont  préoccupés par la sécurité de leurs applications et ont besoin de visualiser dans son ensemble le niveau de risque  assorti des actions pour y remédier : l’outil sélectionné devra impérativement fournir cette vision d’ensemble, ainsi que la justification du plan de correction proposé.

La solution devra répondre aux divers besoins des responsables sécurité : visualiser l’état général de la sécurisation, afin de renforcer les applications les plus vulnérables, disposer d’un plan de correction hiérarchisé, évaluer le risque réel auquel leur organisation est exposée, etc…

Apprentissage d’un codage sécurisé

Dans une optique de maîtrise des coûts et de sécurisation des applications, la solution choisie devra permettre aux développeurs d’améliorer et de renforcer leur technique de codage, de façon à être capable de livrer des applications de plus en plus sûres. Cet apprentissage par l’outil, permet à l’entreprise d’économiser le  coût et le temps qu’exigerait une formation dispensée à l’extérieur.

2.3 Simplicité

Intégration naturelle dans les processus existants  

Il est essentiel pour une organisation qui décide d’installer un logiciel de test de sécurité des applications au sein de son SDLC, que la solution choisie s’intègre naturellement aux processus existants, sans les perturber. Un outil dont la mise en œuvre nécessite des procédures nouvelles et complexes présente deux inconvénients possibles. D’une part, ne pouvant s’intégrer au SDLC, il se maintiendra toujours en dehors de celui-ci,  et par conséquent sera utilisé comme une couche supplémentaire dans les phases de post développement. D’autre part,   son processus d’intégration est si long qu’il nécessitera une augmentation des ressources de l’entreprise, et son implémentation peut prendre plusieurs années. Dans les deux cas, les applications demeurent sous la menace constante des failles de sécurité.

Utilisation immédiate, aucune formation requise

Une solution techniquement complexe et qui nécessite des compétences particulières pour l’interprétation et la mise en œuvre de ses résultats, obligera l’organisation à faire appel à un personnel spécialisé dans le domaine de la sécurité pour la faire fonctionner.

Cette sollicitation d’une ressource experte en interne ou en externe,  ralentira le cycle de développement, ce qui est particulièrement préjudiciable aux environnements Agile et de déploiement continu. En effet, si l’analyse et la mise en œuvre des résultats de tests de sécurité sont réalisées par du personnel extérieur au SDLC, cela implique que la sécurité des applications ne sera prise  en charge qu’après la phase de développement, risquant ainsi de générer à nouveau les problèmes que la solution était censée corriger.

Facilité de déploiement et de mise en œuvre

La solution, pouvant être déployée et mise en œuvre rapidement,  doit être flexible et s’adapter à l’évolution des besoins de l’entreprise, quelle qu’en soit l’échelle.

2.4 Objectifs Métiers

Pour éviter les coûts cachés

Le coût d’acquisition d’une solution de test de sécurité des applications doit inclure le coût du produit et les coûts associés d’intégration, ainsi que les coûts récurrents de fonctionnement et de maintenance.

Le calcul du coût total d’acquisition devra inclure le temps consacré  à l’identification et la résolution de faux bugs  (le temps de résolution de ces derniers est multiplié par 4 par rapports aux bugs réels), le  tri des résultats, la configuration et l’optimisation de la solution, le temps passé à effectuer les tests, les retards et répétitions dans les processus existants, etc…

Pour un déploiement rapide

Nous déconseillons aux organisations complexes les solutions qui requièrent de longs processus d’intégration, de configuration, et des modifications significatives des flux existants. L’implémentation de ce type d’outils peut nécessiter jusqu’à plusieurs années pour être finalisée. Dans ce laps de temps, il est fort probable que des applications ne soient pas traitées par le système de sécurité adéquat, mettant ainsi en danger les organisations qui par ailleurs investissent d’importantes ressources pour sécuriser leurs applications en phase post-développement via des experts externes ou des équipes internes indépendantes de la R&D.

La solution devra, autant que possible, éviter de modifier les processus existants,  et limiter les opérations de configuration et d’intégration, de façon à permettre une mise sur le marché rapide des applications.

3. Sommaire

A moment d’aborder la tâche délicate du choix d’un outil de test de sécurité des applications, Il est naturel de se diriger vers celui qui répondra le mieux aux besoins de votre organisation, et qui sera le plus performant à résoudre les problèmes de sécurité cruciaux pour votre activité.

Dans ce document nous avons souligné les différents paramètres qui sont importants à considérer lors du choix d’une solution de test de sécurité des applications pour votre SDLC. Ils satisfont à quatre critères,  essentiels à une gestion efficace de la sécurité des applications, dans tous types d’organisations:

  • Précision,
  • Clarté,
  • Simplicité et
  • Objectifs métiers

La solution la meilleure, est celle qui se conformera de manière optimale à ces critères.

This post is also available in: Anglais

Learn more about Seeker

More Autres Ressources