Les outils de sécurité applicative

La couche applicative étant devenue la principale source d’incidents de sécurité, les contrôles et tests de sécurité sur les applications sont devenus un enjeu majeur pour les entreprises.

Nous allons décrire ces outils dédiés et expliciter leurs spécificités dans une démarche DevSecOps d’automatisation ou simplement dans la sécurité dans les développements vers un but d’amélioration continue des applications, au même titre que des solutions d’analyse de Qualité du code ou de Performance.

Contenu

SAST ou Static Application Security Testing

Cet outil de tests statiques de sécurité des applications permet aux développeurs de rechercher directement de potentielles vulnérabilités dans le code source de l’application au plus tôt dans le cycle de vie du développement logiciel. Il permet également d’assurer la conformité aux normes de développement et standards de sécurité applicative sans avoir à exécuter le code.

L’analyse consiste ainsi à vérifier un ensemble de règles sur l’intégralité du code de source d’une application et d’identifier la ligne exacte d’une potentielle vulnérabilité et ce dans de multiples technologies.

• Avantages: Intervient au début du cycle de développement logiciel, Réduit les coûts de remédiation, Supporte de multiples langages, Facilite la montée en compétences des développeurs sur le développement sécurisé
• Inconvénients: Nécessite le code source, Ne détecte pas les défauts à l’exécution ou d’environnement, Nécessite un temps de scan parfois conséquent, Génère de nombreux faux positifs
• Quelques exemples d’outils (liste non exhaustive): Checkmarx, Fortify, Veracode, Coverity, Yagaan, CryptoSense et plus sur la page dédiée de l’OWASP.

DAST ou Dynamic Application Security Testing

Cette solution de tests dynamiques de sécurité des applications va permettre de détecter des vulnérabilités et des faiblesses dans la sécurité d’une application au cours de son exécution, généralement utilisée pour les applications Web.

L’outil va utiliser des techniques d’attaques, de type injection ou XSS par exemple mais aussi révéler des problèmes d’authentification, de configuration du serveur, etc. uniquement visibles à l’exécution de l’application.

• Avantages: Ne dépend pas de la technologie applicative, Détecte des vulnérabilités d’exécution et d’environnement, Permet une vison en mode attaquant avec les risques de la surface exposée
• Inconvénients: Nécessite une application déployée Web ou API, Intervient en fin de cycle de développement donc coût de remédiation plus élevé, Ne supporte pas toujours bien l’authentification
• Quelques exemples d’outils (liste non exhaustive) : OWASP Zed Attack Proxy (ZAP), Acunetix, BURP Suite, AppSpider et encore plus sur la page dédiée de l’OWASP.

SCA ou Software Composition Analysis

Cet outil permet de vérifier la composition d’une application en termes de dépendances tierces et de licences. Comme les applications embarquent généralement des frameworks, des librairies Open Source ou propriétaires entre autres, il est nécessaire de vérifier que l’artefact résultant n’embarque pas des composants connus comme vulnérables ou obsolètes mais également qu’il n’y ait pas de défaut de compatibilité de licences.

L’analyse se fera au moment de la phase de Build sur l’artefact généré dans un repository ou non, ou via la configuration des dépendances de l’application ou pour certains via l’analyse des binaires.

• Avantages: Détecte les composants embarqués vulnérables, Permet une cartographie des librairies et des licences, Se met à jour très régulièrement en terme de base de connaissances de vulnérabilités
  
• Inconvénients: Peut générer des faux positifs en fonction de l’outil
• Quelques exemples d’outils (liste non exhaustive) : OWASP dependency-check, BlackDuck, Jfrog XRAY, Sonatype, NPM Audit, CAST Highlight et toujours plus sur la page dédiée de l’OWASP.

IAST ou Interactive Application Security Testing

Le nommage interactif, vient du fait que cet outil va permettre de tester l’application à son utilisation lors de tests de recette automatisés ou humains ou lors d’une interaction technique.

Cette analyse est en temps-réel, donc n’impactera pas les pipelines CI/CD mais nécessite l’ajout d’un agent sur le serveur applicatif et ne couvrira pas l’intégralité de l’application car dépendra des tests réalisés. Egalement cet outil pourra se coupler à un outil RASP (Runtime Application Self-Protection) afin de bloquer l’exploitation d’une vulnérabilité.

• Avantages: Assure une analyse en bout de chaîne pendant la recette, Génère peu de faux-positifs, Peut proposer la fonctionnalité SCA
• Inconvénients: Nécessite une application déployée, Intervient en fin de cycle de développement donc présente un coût de remédiation plus élevé, Ajoute de la charge au serveur, Peut entrer un conflit avec des outils d’analyse de performance, Couvre uniquement ce qui est testé
• Quelques exemples d’outils (liste non exhaustive) : Seeker, Hdiv detection, CxIAST, etc.

Complémentarité et choix

Par conséquent, on remarque bien que ces outils peuvent être complémentaires :

• SAST + SCA pour la partie développement et analyse des composants/licences logiciels
• SAST + DAST pour une couverture plus complète des tests de sécurité, l’un couvrant les défauts de l’autre et vice versa (vue statique et vue runtime)
• SAST + SCA + DAST en standard avec un test d’intrusion additionnel pour les applications critiques par exemple. Le test manuel du fait de l’intelligence apportée dans la création d’un scénario d’attaque permettra une couverture complète
• IAST pour une analyse de sécurité liée au fonctionnel de l’application et à sa technologie car installé sur le serveur

Le choix des solutions dépendra fortement du contexte d’entreprise :

• de l’organisation en termes de méthodologies projet et de promotion de la Sécurité Applicative
• de la maturité des équipes de développement et de l’accompagnement inhérent
• des possibilités d’investissement comme certains outils peuvent avoir un coût non négligeable
• de l’hébergement des solutions, comme il s’agit là de vulnérabilités confidentielles, la question SaaS ou on-premise se doit d’être posée en n’oubliant pas les aspects coûts et scalabilité

Chaque outil aura ses spécificités, ses technologies et langages supportés, donc il sera fortement recommandé de trouver celui ou ceux qui correspondent le mieux à son secteur d’activités et surtout ceux qui permettront de réduire les risques cyber associés.

Par exemple, un des critères pourra être le CIAT (DICT) de l’application:

• un site institutionnel sans formulaire pourra se couvrir par une analyse DAST régulière
• une application exposée sur Internet nécessitera plusieurs analyses complémentaires de part son besoin d’intégrité
• une application qui contient des informations métier critiques ou personnelles devra avoir également des tests avancés

L’utilisation de modèles de maturité et d’analyse de risques peut aussi aider à prioriser les choix en termes d’outillage.

———

L’introduction de tels outils nécessitera d’adapter la politique de sécurité applicative et le SDLC (Software Development Life Cycle); de définir des objectifs de déploiement (couverture du parc applicatif) et de corrections (e.g.: Ratio vulnérabilités découvertes versus remédiées), de former les équipes à leur usage (Workshops et guides pratiques) et d’aider à la qualification et à la remédiation des nouvelles vulnérabilités découvertes.

En conclusion, chaque outil  devra permettre de faciliter les contrôles de sécurité des applications et devra s’intégrer dans l’environnement existant afin d’en faciliter l’adoption par les équipes et de promouvoir l’automatisation des scans de sécurité dans une démarche DevSecOps ou d’amélioration continue.