Duquesne Group Duquesne Group

English version
Recherche et Analyse

Pour éclairer les décideurs dans le domaine de la Continuité d'Activité et de la Sécurité de l'Information, Duquesne Group propose ses analyses et réflexions issues de ses réalisations concrètes en clientèle. Observation critique du terrain par nos experts, contacts permanents avec les principaux acteurs du domaine et expérience vécue dans nos missions de conseil sont nos principales sources. Contactez-nous pour en savoir +
French version
Research

To support decision makers in the management and optimisation of information systems, Duquesne Group delivers in-depth analyses of information technologies, their implementations and their markets. Our research is based on critical observation of the market by our analysts and their on-going contacts with the vendor community, together with hands-on, practical experience from our consulting work. Contact us to find out more


Qualification des logiciels applicatifs : service et sécurité

Un Rapport d'Analyse Duquesne



La qualité de la chaîne de développement du début jusqu'à la mise en production est fondamentale non seulement pour les aspects fonctionnels mais aussi pour le respect des contrats de service et des exigences de sécurité. Cette note de recherche rappelle l’importance du processus de qualification effectué à l’issue d’un développement, et qui souvent, sous la pression des coûts et délais n’intègre pas tous ces besoins.



Le passage en production de tout changement est un événement à risque. Les changements provenant des Etudes, qu’il s’agisse du déploiement d’un nouveau projet ou de l’implémentation d’une maintenance corrective, fonctionnelle ou technique, méritent une attention particulière.

Pour minimiser les impacts sur la qualité de service de la production et donc sur les utilisateurs métiers, un grand soin doit être accordé à la qualification des développements sur mesure ou à celle de l’intégration de progiciels. En effet, l’enjeu majeur pour une DSI est d’être en mesure de fournir à ses clients le niveau de service attendu qui sera décrit dans le contrat de service.

Des exigences de qualité dès l’expression de besoins

Parmi les managers du Système d’Information, le directeur du développement a pour responsabilité directe de vérifier que les insuffisances et imprécisions éventuelles de l’expression de besoins fonctionnels ont été impérativement identifiées et traitées avant l’engagement des étapes de conception. De la même manière lors de changements fonctionnels demandés en cours de développement, il importe d’être vigilant sur la gestion de leur impact.

L'exigence de qualité dès l'expression de besoins est donc un pré requis pour la qualification. En effet, un bon travail de qualification n’est pas suffisant pour réduire le niveau d’incidents applicatifs en production, car d’autres dysfonctionnements peuvent résulter d’une mauvaise conception conséquence d’une mauvaise expression de besoins.

Une implication très en amont de tous les acteurs concernés

Le directeur du développement doit également veiller, dès le début du projet, à l'implication très en amont de tous les acteurs concernés. Cette bonne pratique de base est connue à tous, mais son importance et l'ampleur de la tâche sont parfois sous-estimées.

En effet, les origines des difficultés suite à la mise en production sont diverses. Outre les cas, qui relèvent essentiellement de la responsabilité du directeur du développement, d'une mauvaise conception ou d'une mauvaise expression des besoins, plusieurs points délicats nécessitent l'engagement de la Production, de l'Equipe Système, de la cellule Architecture, etc. On peut citer par exemple :

 le fait que les architectures techniques visées peuvent ne pas avoir été complètement définies et respectées ;
 une mauvaise évaluation des ressources techniques nécessaires à l’atteinte des performances voulues ;
 une analyse insuffisante des perturbations opérationnelles sur la production ;
 enfin, une préparation insuffisante des outils de production, de surveillance et administration peut ne pas avoir été faite convenablement pour accepter les nouveautés.

Par rapport à cette problématique transverse, qui fera l'objet d'analyses approfondies dans les cahiers suivants, nous nous bornons ici à quelques observations.

Globalement, il convient d’être vigilant sur chacun de ces points et d’adopter une attitude d’anticipation et de surveillance du risque tout au long du projet. Pour ce faire, le directeur du projet ou du développement doit se comporter en coordinateur d'une équipe transverse, associant les autres managers de la DSI et l'ensemble des acteurs concernés.

Les architectures techniques d'aujourd'hui – n-tiers, SOA, virtualisation, Web, etc - sont beaucoup plus complexes qu'à l'époque mainframe. Le directeur du développement doit s'assurer de la validation de l'architecture de ses applications, en respectant les instances et les processus de gouvernance technique du système d'information. Il faut y associer tous les acteurs concernés, qu'ils soient à la Production, dans une cellule Architecture ou ailleurs dans la DSI.

Le directeur du développement doit aussi veiller, dès le début du projet, à l’évaluation des besoins en matière de performance et de volumétrie, à la fois en termes de système et au niveau du réseau. Cette évaluation est communiquée à la Production – voire effectuée conjointement avec elle - et régulièrement revue pour s’assurer de sa pertinence. En cas de déviation des mesures correctives pourront être prises.

La perturbation opérationnelle sur la production est difficile à voir par les Etudes. Avec les technologies les plus récentes elle est aussi techniquement plus difficile à évaluer. Cette analyse est donc une tâche importante incombant à la Production à réaliser dès que possible, ainsi que le travail souvent délicat de préparation des outils de production, de surveillance et d’administration.

L’implication en amont de la Production est donc plus que jamais indispensable. Sollicitée trop tardivement, ses exigences seront mal intégrées dans le projet et son propre travail de préparation mal effectué. Ceci peut être préjudiciable à la qualité de service finale et peut conduire à des optimisations ultérieures nécessaires et coûteuses. La Production doit s'impliquer le plus tôt possible, et être associée aux différentes étapes clés et comités techniques jalonnant le cours du projet.

Concernant les tests, les activités se répartissent entre les équipes de maîtrise d’œuvre pour les tests unitaires et pour les tests d’intégration, la maîtrise d’ouvrage pour la recette fonctionnelle, et la production pour la recette technique. Il s’agit dans ce cas de la validation de la conformité du logiciel aux exigences d‘architecture, de performance, de volumétrie, et d’interopérabilité avec l’environnement, et ce dans des conditions proches de la production.

Trois familles d’acteurs (développeurs, production et métiers) sont donc impliquées dès le début du projet avec chacune des rôles et responsabilités bien précis aux différentes phases de développement du projet c’est à dire de sa conception à sa mise en œuvre.

La prise en compte des exigences de sécurité

Aujourd’hui, l’implication d’un quatrième acteur, le Responsable de la Sécurité des Systèmes d’Information (le RSSI), est devenu de plus en plus important pour la prise en compte, en liaison avec les métiers, des exigences de sécurité, tout particulièrement dans le cas d’applications internet voir intranet. En effet alors que les réseaux sont protégés par des pare-feux, les serveurs par des dispositifs adaptés, la majorité des attaques constatées porte sur la couche applicative.

En période de crise on se doit d’être plus attentifs que jamais et se prémunir contre les pertes financières ou pertes d’informations potentielles. Des études (Web Application Security Consortium) ont montré que 85% des sites étaient exposés à des risques d’attaque permettant la lecture, la modification, ou le transfert de données critiques. Le coût de la perte ou du vol de données peut se compter en millions d’euros : par exemple, dans un cas connu, un groupe industriel français aurait eu à déplorer un manque à gagner de 245 millions d’euros suite à une attaque de hacker.

Pour attaquer les applications, plusieurs techniques peuvent être utilisées. La plus connue est l’injection de requête SQL dans la fenêtre de saisie de l’URL mais aussi l’injection de requête de type LDAP pour l’accès aux annuaires ou encore XPath pour les documents XML. Avec l’essor de la communication inter-applications, par exemple entre une entreprise industrielle et ses fournisseurs, sont apparus d’autres types d’intrusion comme les attaques SOAP Web Services.

Ainsi la prise en compte dans le projet de qualification des exigences de sécurité applicative est devenue essentielle. Il existe des solutions et des outils proposés par certains fournisseurs. S’agissant d’un domaine encore relativement jeune, nous y reviendrons ci-dessous dans plus de détail.

La qualification en mode projet

Ayant pris conscience de tous ces besoins, il importe de valider leur prise en compte lorsqu’on arrive à la phase de qualification. C’est un chantier à part entière qui doit être préparé et géré comme un projet de développement.

Trop souvent, soit pour compenser un glissement de planning soit pour minimiser le coût global du projet à tester, certaines impasses sont pratiquées au détriment du résultat final. La démarche préconisée peut paraître lourde, elle est à adapter en fonction de la taille et de la criticité du logiciel à tester de manière à aboutir à un compromis acceptable entre qualité, délai de mise en service et coût.

Un projet de qualification se décline autour des 3 axes - fonctionnel, technique et sécurité - correspondant aux trois types principaux de besoins ou d’exigences évoqués précédemment.

 Ainsi, l’expression de besoins pour le projet de qualification décrit la stratégie de tests adaptée à l’ensemble de ces exigences. Avec l'évolution des infrastructures, la définition de la stratégie de tests est devenue plus complexe, notamment pour les applications qui seront déployées sur des milliers de PC ou exploitées en mode Web. Ici, il faut se poser franchement la question : peut-on tout tester ? Un choix de priorités correspondant aux enjeux du métier bénéficiaire est à faire. Les critères de fin de tests ainsi que les modalités de gestion des anomalies doivent être définis.

Pour satisfaire aux exigences de niveaux de service attendus en production, la qualité technique des développements est à tester. Le choix d’outils de diagnostic ou d’optimisation de performance est nécessaire

En matière de sécurité, pour identifier et corriger les failles éventuelles, pour effectuer les tests de vulnérabilité, de nouveaux outils émergent, comme indiqué ci-après. Il devient indispensable d’y recourir dans le cas de développements internet en particulier lorsqu’il s’agit d’applications critiques pour les métiers.

 Comme dans tout projet, moyens, charges et planning sont à quantifier. Le planning qui, tenant compte des charges estimées et des moyens disponibles, met en évidence les dates clés et préfigure le planning de déploiement. L’évaluation des moyens nécessaires pour la qualification couvre l’ensemble des besoins en ressources humaines, matérielles et logicielles.

L’évaluation des charges est bien évidemment fonction de critères comme l’ampleur des développements à qualifier, du nombre d’interfaces avec l’environnement, des contraintes de l’utilisateur. de tests. Elle s’appuie sur différentes approches comme la méthode des ratios, le nombre de fonctions à tester, le nombre de cas de tests, et tient compte des facteurs influents que sont par exemple le type de développement (itératif, sur mesure, ou progiciel,) la nature du traitement, le langage.

Un suivi du projet est à prévoir pour gérer son budget et son planning et prendre en compte l’impact des divers événements survenant au cours du chantier.

Malgré ces précautions méthodologiques, on n’évitera pas les aléas, des arbitrages peuvent être à faire au cours de la qualification en fonction de la gravité du problème rencontré, de la criticité du projet, des contraintes de planning, des solutions de contournement possible ou autre.

 Une évaluation des risques portés par le projet de qualification est recommandée. Le risque peut résulter par exemple d’une documentation insuffisante ou non à jour, d’un changement des exigences client, de contraintes de délais limitant la profondeur des tests, ou d’une insuffisance de moyens.


Outils de sécurité applicative

Des outils de sécurité applicative font partie de plus en plus des moyens logiciels à prévoir dans le projet de qualification. Au niveau de l’offre, des fournisseurs proposent soit des solutions spécialisées soit une approche basée sur les différentes phases du cycle de vie des applications.

En France, on peut citer FORTIFY, un pionnier en la matière, dont le point fort est l’analyse du code. En revanche, le constructeur HP – et plus récemment IBM - proposent des solutions intégrées, portant sur l’ensemble du cycle de vie. Ces solutions sont encore peu répandues mais prometteuses.

Dans le cas d’HP, la plate-forme de sécurité proposée comprend un ensemble d’outils pour :

• L’analyse de code : les fonctionnalités de l’analyseur garantissent que le code développé est sain et ne comporte pas de faille de sécurité,
• Les tests : le logiciel automatise la détection des anomalies de sécurité dans les applications au cours de la phase d’assurance qualité
• La fourniture d’analyses de sécurité des applications et des environnements avant la mise en production et pendant l’exploitation, et la création de rapports personnalisés (validation de modèles, règles et conformité)

Sur cette plate forme HP intègre aussi la technologie SPI provenant de la société SPI Dynamics acquise par le constructeur pour renforcer son offre d’outils de gestion de la qualité applicative proposée sur tout le cycle de vie des applications.

Compte-tenu de l’importance croissante de l’enjeu, on peut s’attendre à ce que les offres des différents fournisseurs s’enrichissent et s’imposent dans les projets de qualification.

Un investissement garant de la qualité de service

L’investissement dans le projet de qualification apporte une meilleure garantie de l’atteinte du niveau de qualité nécessaire en phase opérationnelle, et donc une meilleure garantie du respect du contrat de service qu’il soit conclu entre les clients et la production en interne ou dans le cas d’une externalisation de la production.

En effet, les problèmes n’apparaissent qu’après la mise en production. Les applications mal testées sont souvent mal maintenues. Les mauvaises performances (fonctionnelles ou techniques) des applications, les failles de sécurité peuvent engendrer des pertes financières.

L’objet premier des tests est d’ordre fonctionnel, mais le besoin de qualification technique est renforcé avec la complexité croissante des nouvelles architectures. Désormais, les besoins de sécurité sont à intégrer dans les projets de qualification.
René Dugué
Mardi 1 Septembre 2009

Home Home    Mail Mail    Print Print    Zoom + Zoom +    Zoom - Zoom -    Share Share


Dans la même rubrique :
< >

Duquesne Research Newsletter