Stratégie IAST, un indispensable ?

L’IAST, acronyme anglophone d’Interactive Application Security Testing, est la promesse d’un testing interactif et en temps réel de l’application ! Qu’en est-il réellement aujourd’hui ? Plongeons au cœur du système ! 

IAST pour Interactive Application Security Testing. 

L’IAST, comme son nom le laisse supposer, est une méthode d’analyse et de test censée éprouver la solidité d’une application face à divers risques de cybersécurité, et cela de manière interactive. Sa principale caractéristique sur le papier est de combiner les analyses dynamiques (DAST) et statiques (SAST) afin de détecter les problèmes de sécurité durant l'exécution de l’application. 

L’objectif principal de cette approche est d’identifier avec une grande précision les failles de sécurité de l’application, pendant l'exécution de celle-ci. Comment ? En parcourant les chemins critiques fonctionnels de l’application, comme pendant une phase de testing plus classique.  

Toutes les interfaces, boutons, formulaires, requêtes vers les API… tout ce qui est amené à générer des données au sein de l’application sera testé pour identifier d'éventuels problèmes de sécurité. 

Le saviez-vous ? 

Saviez-vous que certains outils de SAST font de l'exécution symbolique ? Il s'agit d'exécuter le code pour mieux comprendre les appels entre les fonctions et les transferts d'information, et mieux détecter les failles de sécurité. C'est le cas de la solution OpenText Fortify par exemple ! 

Un bon complément à l’approche DAST et SAST ? 

L’approche SAST (pour Static Application Security Testing) consiste en une analyse statique du code source, sans exécution de l’application. On ouvre le capot et on regarde le moteur à froid, si nous osons l’analogie mécanique. C’est sûrement la méthode la plus efficace pour identifier les vulnérabilités au niveau du code, mais elle peut manquer de contexte d'exécution. 

Cette efficacité provient d’un fonctionnement en boîte blanche. Ce terme est issu des tests d’intrusion (Pentests) et signifie que l’on dispose de la totalité des informations (ici du code) pour pouvoir mener son test dans des conditions “parfaites”. 

L’approche DAST (pour Dynamic Application Security Testing) consiste quant à elle dans le test d’une application en cours d’exécution, sans toutefois observer son code source en même temps. Ce qui est très pratique pour découvrir des failles qui n'apparaissent pas lors de l’observation à tête reposée du code source. Cela permet également de détecter d’éventuels problèmes de sécurité sur le serveur HTTP qui exécute l’application. 

Contrairement au fonctionnement en boite blanche du SAST, l’approche DAST est basée sur une approche en boite grise et/ou boite noire. 

• La boite grise est l’approche qui simule des tests d’intrusion par une personne ayant une connaissance minimale de l’application car elle possède au moins un compte utilisateur (sans privilège la plupart du temps). Elle va essayer d’avoir plus de droits (élévation de privilèges verticale) ou de voir les données des autres utilisateurs de même niveau (élévation de privilèges horizontale). 

• La boite noire est l’approche qui simule des tests d’intrusion de la part d’un attaquant externe, n’ayant aucune information et ne partant de rien. Sans compte d’accès, l’attaquant doit déjà se frayer un chemin vers les parties privées de l’application pour obtenir un accès.

C’est donc là que le positionnement de l’IAST se situe, à la croisée des chemins entre le SAST et le DAST, tentant de combiner le meilleur des deux méthodes tout en éliminant leurs faiblesses respectives.  

Alors, l’IAST, ça marche ? 

L'IAST se distingue par son adaptabilité aux applications et workflow complexes. En particulier les applications mettant en œuvre des processus métiers sophisitiqués, difficiles à reproduire par des robots de scanner DAST. 

Si le SAST est facile à intégrer dans un pipeline (c’est d’ailleurs l’un de nos workpackages consultables ici), le DAST peut être un peu plus complexe car il faut déployer dynamiquement la version de l’application ciblée par les tests. Pour cela, il faut aussi que l’application puisse tourner, dans sa version actuelle, sans crash, car il est impossible de faire la différence entre un crash issu d’un problème de code et un crash déclenché par les attaques. 

Pour ce qui est de l’IAST, les options sont un peu plus réduites, car il faut parcourir l’application pour tester les chemins métiers :

• Utiliser un régiment de testeurs durant les tests est coûteux et particulièrement inadapté à la philosophie DevOps (trop de manuel, incompatible avec un code applicatif mis à jour plusieurs fois par jour).

• Soit on utilise l’approche DAST pour parcourir l’application et pendant que la partie IAST “regarde”. L’utilisation de deux outils augmente les coûts et le parcours de l’application par des robots réduit la qualité du test et la sélection des chemins critiques est plus aléatoire. 

• Automatisation dans le pipeline CI/CD 

L’IAST peut être configuré pour s’exécuter automatiquement comme une porte de sécurité (étape du pipeline). Cela permet aux développeurs d'identifier et de corriger les vulnérabilités avant que le code ne soit déployé en production. 

• Feedback rapide

En offrant des résultats en temps réel à chaque passage dans le pipeline, l'IAST réduit le délai entre la détection et la correction des vulnérabilités. Cela contribue à maintenir un rythme de développement rapide sans sacrifier la sécurité.

• Collaboration entre équipes

En fournissant des informations précises et exploitables sur les vulnérabilités directement dans les outils de développement (comme les IDE ou les plateformes de gestion de tickets), l'IAST facilite la collaboration entre les équipes de développement, de sécurité et d'exploitation.

• Analyses des outils tiers

Il est possible pour une approche IAST d’englober les outils tiers comme les frameworks et les bibliothèques, et ainsi éviter les vulnérabilités externes. Par outils tiers on entend les développements réalisés par d’autres équipes et non les dépendances, le test de sécurité associé à ces dernières étant réalisé via les outils de SCA (Software Composition Analysis).

Des limites réelles sur l’approche IAST 

Si l’IAST présente de nombreux avantages, certaines limites peuvent mettre en cause la pertinence d’une stratégie IAST. 

Pour activer ses fonctionnalités “interactives”, la solution IAST a parfois besoin d’intégrer une sonde (un bout de code) à l’applicatif. Ce procédé technique permet de collecter et de remonter des informations rapidement et en temps réel sur l’application ! Or, ces sondes sont, dans les faits, des portions de codes au sein même des applications testées, ce qui impacte directement le cycle de la Quality Assurance (QA), et peut créer des effets de bords importants sur le reste du code de l’application ! 

De plus, l’IAST, pour être efficace, nécessiterait de passer par tous les chemins fonctionnels critiques de l’application ! Si on passe outre le fait de confier cette activité à un robot, cela représente une charge de travail importante de préparation, qui ne pourrait être assumée que par un régiment de testeurs plus ou moins aguerris, ou un bataillon de forces vives disposant de cahiers de tests ! Confier une telle tâche aux développeurs, déjà sous pression pour terminer leurs sprints techniques ou fonctionnels, s’apparente à une forte surcharge dont la mise en place ne résiste pas à l’épreuve des faits. 

Et l’automatisation ? 

Pourrait-on imaginer automatiser les actions humaines, les remplaçant par des tests dynamiques (DAST) ? 

Sur le papier oui, mais dans les faits, pour être efficace, un scan DAST doit être scénarisé, et les chemins critiques de l’application parcourus pour entraîner le robot. Pour être performant, une telle scénarisation apparaît plutôt longue et proche d’une mise en place manuelle des tests. 

E2E, la solution ? 

Bon, si les tests dynamiques (DAST) ne sont pas adaptés, peut-être que les tests End-to-End (E2E, de bout en bout en français) seront plus idoines ? Eh bien, pas vraiment… 

Contrairement à des tests unitaires ou d’intégration qui se concentrent sur des parties spécifiques du système, les tests E2E simulent des scénarios réels impliquant toutes les couches de l'application (frontend, backend, bases de données, API, etc.). 

Mais là survient un problème. Les tests E2E, s’ils sont essentiels, sont très coûteux à mettre en place. Afin de conserver une maîtrise des coûts, il est souvent décidé de raboter au maximum cette partie End-to-End pour privilégier les tests back only pour tester tous les canaux de communication (endpoints). 

L’IAST, pour quelles approches ? 

Au vu de ces limites, peut-on envisager l’IAST comme une solution de test de sécurité unique et couvrant les enjeux de l’Application Security ? Au moment où nous rédigeons cet article, il semble compliqué de baser sa stratégie de tests sur une politique IAST, d’autant que les limites de l’approche font disparaître les avantages liés à “l’interactif”. 

Poussé dans un pipeline, l’IAST n’a plus rien d’interactif, et sans personne pour parcourir l’application durant ses observations, son utilité est proche de zéro.  

Il existe d’autres solutions, bien plus adaptées et qui sont déjà pleinement opérationnelles et en phase avec les contraintes et enjeux du développement applicatif : 

• L’approche SAST est la meilleure “première brique” aux tests de sécurité. Réalisée par un outil capable de faire de l’exécution symbolique (on se rapproche du DAST), et intégrée au pipeline CI/CD aux bons endroits (en accord avec le gitflow de l’application) c’est un pas de géant pour le traitement de la sécurité dans l’itération. 

• Un bon RASP (Runtime Application Self Protection) qui est une solution de sécurité déployée uniquement sur une application, au lieu d’un poste ou d’un réseau. Cette solution protège l’application des attaques, sait faire la différence entre une attaque qui pourrait réussir et une attaque qui sera en échec, sait notifier ou bloquer les attaques en temps réel. Non intrusive (pour les meilleurs produits, elle ne nécessite pas d’ajout de code dans l’application), elle ne causera pas d’effets de bords ou de sueurs froides au responsable QA.

• Pour compléter l'approche et protéger les API (un monde à part entière au sein de celui du développement applicatif), une solution d'API Security, car les failles de sécurité et leurs exploitations y sont très spécifiques (cf. OWASP Top 10 API Security Risks, mis à jour en 2023), mais cela fera l'objet d'un article dédié sur notre blog !