La vocation de cette communauté est de sensibiliser les devs et le Métier à la sécurité des applications. Étant développeuse depuis maintenant quelques années, je m’interroge sur la place accordée à la sécurité dans le processus de développement. Le rôle des devs étant d’apporter de la valeur ajoutée au Métier. Et ce quel que soit le domaine où nous intervenons.
Le top 10 est un bon début pour se familiariser aux risques et failles de sécurité que l’on peut rencontrer. Une fois que c’est fait, comment est-ce qu'on s’organise ? Par où commencer ?
L’OWASP et ses contributions permettent de répondre à ces questions.
La sécurité est l’affaire de toute l’équipe, toutes les personnes au plus près de l’application. Voyons comment les faiseurs de valeur ajoutée peuvent intégrer la sécurisation au processus de développement.
Les enjeux
Devant le nombre grandissant de nouvelles applications développées, mises à jour et déployées particulièrement depuis le début de la pandémie du COVID-19, WhiteHat Security a augmenté la fréquence de ses publications. Jusque-là annuelles, elles sont maintenant mensuelles. La menace a évolué elle aussi et s’est étendue parallèlement à l’explosion du développement d’applications.
La situation a mis en lumière le manque de talents disponibles en Cybersécurité. Ainsi que le manque général de ressources pour de nombreuses industries qui luttent pour gérer les montées de version et corrections de centaines d’applications.
En 2009, WhiteHat faisait état d’une durée de 30 à 106 jours pour réparer les vulnérabilités du top 10 dans les applications en production. En 2019, réparer des failles présentant des risques faibles nécessitait 97,8 jours, 102,3 pour des risques élevés, 51,7 jours pour les critiques.
C’est important parce qu’il faut 7 à 14 jours pour rendre possible l’exploitation d’une CVE récemment divulguée. Alors qu’il faudra 85-100 jours à une entreprise pour patcher cette vulnérabilité.
Assurer la sécurité permet de faire des économies : ne serait-ce qu’en rendant possible la continuité des services. La notion de gestion des risques est capitale.
La qualité impacte fortement la capacité des équipes à corriger rapidement leur solution. “Accelerate” de Nicole Forsgren, Jez Humble et Gene Kim démontre scientifiquement la corrélation entre les performances économiques et les performances de livraison logiciel d’une organisation. La qualité du logiciel permet d’accélérer la vitesse de correction. L’indicateur “Mean Time To Restore (MTTR)” est très révélateur de la maturité des tests de l’application. Les pratiques de développement Agile comme le TDD viennent réduire ce temps nécessaire à la correction. Le fait que le TDD couvre les cas d’usage, les erreurs et cas de mésusage pourrait y être pour quelque chose.
https://securityboulevard.com/2020/06/why-it-takes-10x-longer-to-patch-than-it-does-to-exploit/
https://rietta.com/blog/patch-production-faster-with-agile-development/
https://snyk.io/series/open-source-security/
Le rôle des devs
Nous, les créateurs d’applications, avons pour mission de traduire l’activité et les besoins d’un client en programme. Programme dont la vocation première est de rapporter de l’argent ou d’en faire économiser. La moindre indisponibilité, vulnérabilité ou erreur peut coûter très cher. D’autant plus si la confiance des utilisateurs finaux est dégradée. Comme l’indiquait Thomas Gentilhomme, dans son interview, en matière de sécurité, quand les entreprises prennent conscience de son importance, il est souvent déjà trop tard.
Qualité et Sécurité vont de pair. On imagine mal un chef cuisinier rémunéré pour créer des recettes gastronomiques, les faire servir dans des assiettes sales et partiellement cassées. À chaque bouchée, les clients pourraient tomber malades ou se blesser. Imaginons maintenant, un site à fort trafic où des transactions pourraient faire tomber le site, compromettre les moyens de paiement des clients ou tenir les devs en hypervigilance. Un peu plus plausible.
Nul.le ne s’improvise experte ou expert. Pour renforcer mon code, j’ai d’abord chercher les outils adaptés. Mon appétence pour les tests m'a ensuite amenée à découvrir le STDD (Secure Test Driven Development) puis le Secure by Design.
Le STDD consiste à implémenter le code de production en étant guidé.e par des tests focalisés sur la sécurité. Cette méthodologie implique des tests de sécurité d'application statique et dynamique (SAST, DAST). Selenium ou OWASP Zap sont des outils pouvant être utilisés pour implémenter ces tests.
Le Secure by design est le concept mettant la qualité au service de la sécurité. Les devs renforcent le cœur de métier et fonctionnalités générant des revenus. Ce qui est rendu possible par de nombreux échanges entre devs et Métier sur les cas d’usage extrêmes, les limites des cas d’utilisation.
Heureusement, l’OWASP propose de nombreuses solutions pour cadrer et assurer la résistance des applications aux attaques et incidents.
Sources :
https://www.linkedin.com/pulse/security-test-driven-development-stdd-surendran-ethiraj/
Quelques acronymes et définitions
CWE : Common Weakness Enumeration (Énumération des Défaillances Communes), c’est la liste des types de défaillances rencontrées dans les applications comme dans l’équipement informatique. Elle est directement liée au top 10 de l’OWASP. C’est une base de données publique sponsorisée par le gouvernement américain. https://cwe.mitre.org/
CVE : Common Vulnerabilities Exposure (Exposition des Vulnérabilités Communes), ce sont des méthodes de référence pour les vulnérabilités publiquement divulguées. Chaque CVE est rattachée à une CWE. https://cve.mitre.org/
NIST: National Institute of Standards and Technology. https://www.nist.gov/
NVD : National Vulnerability DataBase. https://nvd.nist.gov/
OSINT : Open Source INtelligence, il s’agit d’une technique des renseignements fédéraux américains qui consiste à fouiller toutes les données pouvant être rassemblées depuis les sources gratuites et publiques concernant un individu ou une société
STLC : Software Testing Life Cycle, Cycle de Vie du Test d’Application
SDLC : Software Development LifeCycle, Cycle de Vie du Développement d’Application
SCA : Software Composition Analysis
CPE : Common Platform Enumeration
SSDLC : Secure Software Development Life Cycle, Cycle de Vie du Développement d’Application Sécurisée
Mitigate risks : mitiger les risques consiste à mettre en oeuvre des mesures pour limiter voire éliminer des risques d’attaques ou incidents
Data tampering : littéralement “falsification de données”, c’est la modification délibérée de données en contournant les autorisations
Les projets matures ou Flagship
Lien : https://owasp.org/projects
Une vingtaine de projets phare de l’OWASP existent, à ce jour. Ils sont tous liés les uns aux autres. Et constituent un guide naturel dans les connaissances de la fondation. Bien qu’il existe une version française du Top 10, toutes les références sur lesquelles je me suis appuyée pour cet article sont exclusivement disponibles en anglais.
Donner une vue agrégée des différents indicateurs de sécurité : OWASP DefectDojo
Lien : https://owasp.org/www-project-defectdojo/
Le projet : Utile pour avoir une vision de l'état de l’application, outil de suivi des tests.
Détecter les vulnérabilités publiquement connues dans les dépendances d’un projet : OWASP Dependency Check
Lien : https://owasp.org/www-project-dependency-check/
Le projet : En cas de détection, cet outil génère un rapport qui pointe vers les CVE associées.
Alerter en cas de faille dans les dépendances externes : OWASP Dependency Track
Lien : https://owasp.org/www-project-dependency-track/
Le projet : Sur la base de la liste des dépendances, l’outil alerte en cas de faille. Ici, c’est une approche plus poussée qu’avec un SCA comme OWASP Dependency Check.
Renforcer l’application face aux requêtes malicieuses : ZAP
Lien : https://www.zaproxy.org/
Le projet : c’est un scanner d’application qui analyse les réponses aux payloads malicieux envoyés vers l’application, dans une sandbox.
Connaître les contre mesures aux failles et risques : Top 10 Proactive Controls
Lien : https://owasp.org/www-project-proactive-controls/
Le projet : Pour se lancer dans la mitigation, le Top 10 Proactive Controls est un bon point d’entrée.
Aperçu du Top 10 Proactive Controls
Chaque catégorie liste les étapes permettant d’implémenter les contrôles nécessaires. Là où le Top 10 est orienté risques et vulnérabilités, le Top 10 Proactive Controls contre mesures.
Prenons le premier point pour exemple : Définir des critères de sécurité
1 - structure de la page
2 - traduction succincte du contenu
S’assurer de bien remplir les pré-requis en matière de sécurité : ASVS - Application Security Verification Standard
Lien : https://owasp.org/www-project-application-security-verification-standard
Le projet : Pour s'appuyer sur une checklist de la sécurité des applications, l'OWASP a le projet ASVS. C’est une base pour tester les contrôles de sécurité. Elle fournit une liste de pré-requis pour le développement sécurisé.
Organisation en 14 chapitres avec 3 niveaux chacun
Le niveau 1 est pour les applications avec un niveau minimum. Ce niveau est complètement testable pour la pénétration (penetration testing).
Le niveau 2 est recommandé pour la plupart des applications. Celles qui contiennent des données sensibles nécessitant une protection.
Le niveau 3 est pour la plupart des applications dites critiques : celles qui pratiquent des transactions de grande valeur, qui contiennent des données sensibles médicales ou encore toutes applications impliquant le plus haut niveau de confiance.
La légende fait la distinction entre Acceptable et Appropriée :
- est considérée comme acceptable, toute pratique qui serait le minimum attendu pour un niveau et une thématique donnés
- est appropriée, chaque pratique correspondant au niveau abordé et au niveau inférieur. Bien que les intitulés soient identiques, il s’agit d’aller plus loin.
Dans la pratique, il est fortement recommandé aux entreprises d’analyser en profondeur les risques caractéristiques liés à la nature de leur activité. Les listes sont disponibles en CSV, JSON ou autres formats susceptibles d’être utilisés comme référence ou de manière programmatique.
Chaque chapitre commence par un rappel de l’objectif du contrôle abordé. Un état des lieux est fait. Viennent ensuite des rappels sur les rôles et approches que l’on peut trouver en entreprise. L’accent est mis sur le besoin et la volonté d’adopter des principes de sécurité agiles.
Plusieurs sections réparties par thèmes listent les pré-requis en indiquant leur niveau et la CWE à laquelle ils sont rattachés.
Extrait de la section Cycle de vie du développement sécurisé d’applications du premier chapitre Architecture, Design et Modélisation de menace
Notez les liens entre parenthèses. Ce sont des références au Top 10 Proactive Controls. “C1” renvoie vers la définition des critères de sécurité.
Le premier critère,par exemple, consiste à vérifier l’utilisation d’un cycle de vie de développement sécurisé d’applications qui considère la sécurité à chaque étape de développement.
Pour s’assurer que ces critères sont bien remplis et être alertées en cas de régression, les équipes peuvent mettre en place des stratégies de tests.
Tester efficacement : WSTG - Web Security Testing Guide
https://owasp.org/www-project-web-security-testing-guide/v42/
WSTG - Web Security Testing Guide
Le projet : Ce guide sur les tests de sécurité Web permet de s’initier à la pratique. Ce n’est pas une liste de vérification exhaustive. Chaque catégorie devrait être abordée en gardant à l’esprit les risques liés aux besoins Métier de notre application. Penser comme un pirate sera bénéfique pour les tests comme pour la mitigation des risques.
Modèle d’un cycle de vie de développement logiciel générique
De la définition du besoin à la maintenance de l’application, les coûts de réparation des bugs de sécurité sont de plus en plus élevés. Tester permet de repérer ces bugs au plus tôt.
Ce guide contient :
- une analyse
- une approche pratique
- des objectifs
- des méthodologies de test
- des outils et des références
L’introduction présente un ensemble de concepts et pratiques fondamentaux. Notamment la Modélisation de la menace. En bref, chaque cas d’usage (use case) fonctionnels s’accompagne de son cas de mésusage (misuse case). Bien que cela apporte de la visibilité sur la vision du système par un attaquant, cette modélisation ne garantit pas automatiquement la bonne qualité du système.
L’OWASP testing framework a pour but d’aider les entreprises à mettre en place une stratégie de test complète. Il rassemble des techniques et des tâches appropriées à chaque étape du développement.
Flux de travail de test d’un cycle de vie de développement logiciel typique
Le chapitre Web Application Security Testing entre un peu plus dans la pratique. La section Business logic testing liste des outils et références utiles pour tester les failles dans la logique Métier. ZAP ou l’OWASP Zed Attack Proxy est mentionné, cet outil permet de tester de manière dynamique le comportement de l’application en réponse à l’envoi de payloads malicieux prédéfinis.
Une autre section Client-side testing se focalise sur les tests côté navigateur.
Trouver rapidement les ressources et informations sur un sujet donné : Cheat sheet Series
Lien : https://cheatsheetseries.owasp.org/
Le projet : La fondation publie une série d'antisèches pour aider dans notre montée en compétence dans la sécurité. J’en ai compté 78. Elles sont très pratiques pour aborder un thème particulier, de façon concise.
L’antisèche sur la sécurité AJAX liste des rappels et avertissement pour une communication sécurisée entre le navigateur et le serveur du site visité.
Celle sur le Threat Modeling (Modélisation de la Menace) présente cette approche. Une série d’étapes indiquée aide à se lancer.
Évaluer le niveau de maturité pour l’améliorer avec une roadmap : SAMM - Software Assurance Maturity Model
Lien : https://owasp.org/www-project-samm
Le projet : Bien que ce framework soit destiné à la gouvernance, il offre l’opportunité de trouver des axes d’amélioration spécifiques à l’application visée. Surtout, en prenant en compte le niveau de maturité de l'équipe en sécurité.
L’interview donne l’état des lieux des différentes composantes du Métier.
Aperçu de l’interview Gouvernance
Aperçu de l’interview Design
Aperçu de l’onglet Score
Aperçu de l’onglet Roadmap
SAMM calculator developed by an OWASP partner
Aperçu de la page d’accueil de la calculatrice SAMM
Aperçu de la calculatrice SAMM
Le projet : Concord, un partenaire de l’OWASP a développé une calculatrice en ligne pour simplifier l’évaluation.
Pour conclure
C’est à la fois stimulant et impressionnant de constater qu’en Informatique, on a jamais fini d’apprendre. Être dev et être experte ou expert en cybersécurité sont deux rôles différents et complémentaires. Pour citer l’un des slogans de l’OWASP : “la vie est trop courte, la sécurité c’est dur, trichez !”.
Faites-le avec l'OWASP. Vous êtes même libres de contribuer.
.png)
.png)
