La prise en compte de l’aspect sécurité

Durant ces dernières années, nous avons pu constater que la recherche dans le domaine de la validation et de la vérification des exigences de sécurité des applications critiques montre une très forte augmentation. Une grande attention est portée aux propriétés de sécurités, les politiques de contrôle d’accès, les vulnérabilités etc, que nous appelons exi- gences de sécurité, tel que nous l’avons détaillé en section 2.2. Nous sommes arrivés à un stade dans le développement de systèmes critiques matures et stables et lors d’une évolution qu’il est important de garantir la continuité de cette stabilité. Nous nous ren- dons compte que nous souhaitons préserver ces exigences de sécurité lors de l’évolution du système.

Beaucoup de travaux portent sur le test de non-régression pour les fonctionnalités du système, ainsi, Yoo et Harman [YH10] mettent l’accent sur le besoin de continuer l’investigation du domaine de test de non-régression pour des exigences non fonctionnelles (dont les exigences de sécurité font partie). D’après nos connaissances, très peu de travaux, sont dirigés dans le sens de la re-validation des exigences de sécurité lors d’une évolution du système. Ce processus nous l’appelons test de non-régression pour la prise en compte de la sécurité ou encore Security Regression Testing (SRT).

Nous retrouvons l’évocation du besoin de test de non-régression pour la sécurité dans les travaux sur les méthodologies agiles [AGA10, Kon06]. Dans [Kon06], l’auteur pro- pose d’utiliser des misuse stories, contraires aux user stories et les considère comme une possibilité de prendre en compte les exigences liées à la sécurité. D’autre part, il propose d’utiliser les tests dédiés à ces misuse stories pour s’assurer que des régressions de sécurité n’ont pas été introduites. Mais, aucune technique en particulier à utiliser n’est précisée à ces propos. Les études menées dans les projets sur le System Developpement Life Cycle

3.4. Synthèse (SDLC) de OWASP11, tel que détaillé en [Meh], surlignent l’importance du test de non- régression lors de la vérification des vulnérabilités du système. Ces études permettront de mieux analyser les problématiques de sécurité pour les créations des futures systèmes.

D’autre part, nous retrouvons des travaux récents par Hwang et al. [HXEK+_{12]. Ils}

proposent trois techniques pour les politiques de contrôle d’accès, spécifiés en XACML et la sélection de tests de non-régression lors de l’évolution des politiques basées sur : (1) la mutation des politiques de contrôle d’accès, (2) leur couverture et (3) évaluation des enregistrements de demandes.

La première technique sélectionne des règles ri, issues d’une politique P et crée des

mutants de la police, notés M (ri) en changeant la décision sur ri. Cette technique sélec-

tionne des tests qui révèlent des comportements différents de la politique en exécutant les tests sur le programme en interaction avec la politique P et ses mutants M (ri). Elle est

très coûteuse parce qu’elle exécute un test 2xn fois, n étant le nombre de règles dans une politique.

La deuxième technique observe les règles de la politique qui sont couverts par les tests en exécutant les tests sur le programme, lié à la politique de contrôle d’accès, et établie une corrélation, comme la technique précédente, entre les règles et les tests.

Enfin, la dernière technique enregistre les demandes des points de vérifications de la politique lors de l’exécution du test sur le programme. Ensuite, les tests qui encapsulent les différentes décisions pour la politique P et la politique modifiée P’ sont sélectionnés.

3.4

Synthèse

Dans le processus MBT que nous considérons (cf. section 2.3), l’évolution n’est pas prise en compte i.e. lors de l’évolution du modèle l’ingénieur de validation est obligé de régénérer tous les tests à partir du nouveau modèle. Le référentiel de tests est ensuite mis à jour avec les nouveaux tests. Ceci est un problème d’efficacité et de coût dans l’analyse des tests de non-régression de très grands systèmes industriels. Tel que précisé par Jiang et al. dans [JTG+_{10] la régénération complète de la suite de tests d’un modèle du projet}

Microsoft de test de documentations de protocoles (protocol documentation test project) peut prendre plusieurs heures voire même une journée. Ensuite, l’ingénieur vérifie toutes les parties non affectées. Cette étape peut prendre plusieurs jours, voire même semaines en fonction de la grandeur du modèle.

Une autre possibilité est d’utiliser la stratégie retest all, ce qui présume que les fautes peuvent être introduites n’importe où dans le système. Néanmoins, cette stratégie ne fait aucune différence entre une faute classique ou une faute suite à l’exécution d’un cas de test obsolète. Le juste milieu entre ces deux approches est de ne pas considérer que toutes

les parties dans le système sont impactées i.e. d’utiliser une approche sélective.

Ainsi, notre objectif est d’éviter la régénération complète des tests, en effectuant une analyse des évolutions dans le modèle et ensuite classifier les tests issus de la suite de tests initiale. D’après Leung et White dans [LW89], le processus de maintenance des systèmes qui évoluent demande une catégorisation des tests en : obsolete, reusable and re-testable par rapport aux changements et ensuite mise à jour du référentiel de tests. Suite à cela, nous souhaitons distinguer : (i ) les éléments qui n’ont pas changé (ceci ne demande à priori aucune régénération de tests), (ii ) les éléments qui ont changé (ceci demande une nouvelle génération de tests spécifiques pour ces éléments ou cela demande une modification de la version précédente du test) ;

Pour cela, nous proposons une méthodologie et un outil qui permet la gestion d’une ou plusieurs évolutions du système, pour les exigences fonctionnelles (cf. chapitres 6 et 7) et de sécurité (cf. chapitre 8). Dans ce cas, l’ingénieur de validation met à jour le modèle à partir des exigences issues de la nouvelle spécification. De nouveaux tests sont produits en appliquant la génération sélective de tests (Selective test generation method, notée aussi SeTGaM). Ensuite, un composant nommé Smart Publisher est utilisé pour stocker et organiser les tests. Le référentiel de tests est mis à jour avec ces tests ainsi que leur statut pour la nouvelle version, permettant une traçabilité des cas de tests entre les différentes versions. La méthode que nous proposons est indépendante de l’outil de génération de tests, même si l’outillage que nous proposons est associé à l’outil Smartesting CertifyIt.