Le test de sécurité

Que sont les tests de sécurité ?

Les tests de sécurité (TS) sont l'une des exigences non fonctionnelles (ENF) les plus critiques, car ils laisseraient des actifs, tels que des serveurs ou des données, inoffensifs pour les intrus qui y pénétreraient et les exploiteraient si rien n'est fait pour empêcher les cas d'utilisation malveillante de se produire.

En raison de l'importance des enjeux, la ST a élaboré un grand nombre de principes, de pratiques et d'outils qui traitent de multiples aspects de la sécurité.

Parmi les modèles de sécurité les plus connus, la "Triade de la CIA" qui est d'environ [falcongaze.com 2021]. 

• Confidentialité: ce qui est utilisé pour protéger les actifs
• Intégrité: ce qui est utilisé pour maintenir l'intégrité des données.
• Disponibilité: ce qui est fait pour que les données soient disponibles lorsque les utilisateurs réguliers en ont besoin.

Ces aspects fondamentaux contiennent des principes généraux et des principes de conception :

‍

Ce modèle de l'ICA est parfois étendu à six éléments avec ce que l'on appelle l'"Hexade Parkerienne" [Pender-Bey 2012] :

• Confidentialité
• Possession ou contrôle
• Intégrité
• Authenticité
• Disponibilité
• Utilitaire
  

Quels que soient les attributs, la ST doit être incluse dans les nombreuses activités du SDLC, comme toute autre NFR :

• au moment de l'idéation lors de la création d'épopées en identifiant les NFR liées et éventuellement les indicateurs avancés [SAFe 2021-34] si la sécurité est un atout pour les propriétaires d'entreprise
• au niveau de la planification du sprint tout en essayant d'aborder les quatre parties des quadrants des tests agiles [Marick 2003][Crispin 2011][Bach 2014][Crispin 2021].
• au moment de la conception avec une approche de modèle de menace [Juuso 2019] sur les actifs
• au moment du codage avec des outils de test statique de la sécurité des applications (SAST) [Koussa 2018] pour analyser les vulnérabilités du code source et des outils d'analyse de la composition des logiciels (SCA) [Koussa 2018] pour récupérer les menaces des composants open source .
• au moment de la révision du code, où la gestion des vulnérabilités et des menaces à partir des retours d'information de SAST/SCA est facilitée par un coaching des développeurs basé sur la stratégie de test.
• au moment de l'acceptation de la version avec des politiques de réussite/échec examinées manuellement ou automatiquement avec des portes de qualité automatisées dans le pipeline DevOps.
• au moment de l'exécution avec 

• Les outilsDynamic Application Security Testing (DAST), Interactive Application Security Testing (IAST) et Run-time Application Security Protection (RASP) [Koussa 2018]. 
• Activités de pentesting et d'audit [OSSTMM 2010] [Moustier 2019-1].
• les actifs d'infrastructure tels que les pare-feu et les pots de miel [Spitzner 2002] [Moustier 2019-1].

Impact sur la maturité des tests

Outre les techniques et outils de test spécifiques au ST, ce type de test infère également une attention particulière concernant l'organisation selon le principe de séparation des tâches. Une autre raison est liée à l'exigence de " test indépendant " de l'exigence de l'ISTQB [ISTQB 2018] : plus vous connaissez le système, plus vos tests seront orientés. En ce qui concerne les tests réguliers, nous espérons que tout le monde connaît la différence entre les tests en boîte noire et en boîte blanche :

• Avec le test de la boîte noire, vous serez confronté à la même situation qu'un intrus externe.
• avec le White Box Testing, vous pouvez déjà connaître les vulnérabilités existantes et essayer de les exploiter.

Ces deux contextes différents fournissent des situations de test différentes selon les principes de test [ISTQB 2018].

ST fournit plus de saveurs de stratégies de test de vérification qui tentent de tirer profit de ces différents contextes [OSSTMM 2010] [Moustier 2019-1] :

• Aveugle: les développeurs sont au courant des attaques - cela se produit lorsque les cas de test sont connus par l'équipe ainsi que lorsque les tests ont lieu.
• Double aveugle: le testeur/attaquant ne sait rien du système et les développeurs ne savent rien des attaques (ni de la façon dont le testeur/attaquant procède, ni du moment où cela se produit).
• Boîte grise: Les développeurs connaissent une partie du contenu de l'attaque ou le testeur/l'attaquant connaît une partie du contenu à attaquer.
• Double boîte grise: les développeurs et le testeur/attaquant disposent de certaines informations de l'autre équipe.
• Tandem: les développeurs et les testeurs/attaquants collaborent de manière transparente.
• Inversion: les développeurs ne savent pas quoi ni quand de l'attaque, mais le testeur/l'attaquant connaît certaines informations sur le système visé.

‍

Dans un contexte agile, toutes les techniques et tous les outils exposés ci-dessus doivent être réorganisés pour s'adapter à un SDLC itératif axé sur la valeur ajoutée.

La valeur ajoutée doit être pensée en termes de risque, donc en termes de probabilité et d'impact sur les actifs de valeur. Ensuite, pour déterminer quelle pratique doit être mise en œuvre à quelque niveau que ce soit, il convient d'adopter une approche de test basée sur le risque (RBT) afin de réduire la surface d'attaque des vecteurs d'attaque.

‍

Pour réaliser une approche RBT, le modèle du fromage suisse [Reason 2006] peut être utilisé pour ajouter des contrôles supplémentaires ou renforcer les contrôles existants.

Illustration tirée de [Moustier 2019-1].

Classiquement

• les vecteurs d'attaque externes sont traités avant les menaces internes
• les vulnérabilités critiques détectées sont corrigées en premier
• la remédiation des vulnérabilités déjà déployées sur le site legacy fait l'objet d'un "droit acquis"- c'est-à-dire qu'elle est ignorée - jusqu'à une date donnée afin de permettre aux équipes d'apprendre à les gérer ; entre-temps, toute nouvelle vulnérabilité est immédiatement corrigée selon l'approche Kaizen

‍

Quel que soit le contexte du produit, il y a une chose à garder à l'esprit, surtout avec les vulnérabilités dans le code, même si le Dev est responsable d'avoir introduit les vulnérabilités et de les corriger, c'est le Product Owner qui est responsable de la planification de la remédiation. Ces remédiations sont une bonne occasion d'introduire du refactoring en même temps et de réduire la dette technique.

Le point de vue d'Agilitest sur cette pratique

ST est l'exemple emblématique qui met en évidence la nécessité de prendre soin des NFRs. Il ne suffit pas d'avoir un produit fonctionnellement conforme ; si les actifs construits sont précieux, des personnes malveillantes tenteront de les voler ou de les exploiter. Il est donc essentiel de multiplier les tests sur votre solution.

‍

Pour découvrir l'ensemble des pratiques, cliquez ici.

‍