Posons le décor. Le marché mondial DevSecOps a été évaluée à 2,79 milliards de dollars en 2020 et devrait croître de 24% par an de 2021 à 2028. C’est une inéluctable réalité : les applications doivent être hautement sécurisées, et la demande d’automatisation dans ce domaine a explosé.
De plus, la pression sur les équipes informatiques est croissante. Elles subissent les changements structurels des systèmes d’information qui découlent des régulations et des enjeux d’innovation.
Aussi, pour pouvoir tenir les engagements en termes de résilience, disponibilité et sécurité des applications, ces équipes doivent hiérarchiser leurs activités et optimiser leurs ressources limitées.
Il ne faut pas être expert pour comprendre qu’il ne sera jamais possible de corriger toutes les vulnérabilités des applications. Dès lors, il convient surtout de mettre l’accent sur les failles les plus critiques pour l’entreprise. Pour y parvenir, l’approche « secure by design », consistant à intégrer la sécurité dès la conception des systèmes logiciels, est tout indiquée.
Nous le verrons, il existe bien des outils dédiés aux tests de sécurité comme SAST, DAST, et SCA. Cependant, aucun de ces derniers ne peut répondre à tous les besoins de sécurité. Dans ce contexte, la gestion des vulnérabilités fondée sur le risque (Risk Based Vulnerability Management) peut aider les équipes IT à cibler efficacement leurs efforts pour améliorer la sécurité des applications.
Security by Design : 5 principes pour anticiper les enjeux de sécurisation
La sécurité des logiciels est un enjeu majeur pour protéger les données des utilisateurs et minimiser les risques cyber. C’est pourquoi l’industrie du développement logiciel préconise d’intégrer la sécurité dès le début des projets et tout au long de leur cycle de vie. Cette approche de la cybersécurité appelé Security by Design (ou « sécurité par la conception « ) est désormais obligatoire depuis l’adoption du Cyber Resilience Act par Bruxelles en 2022.
En pratique, la Security by Design consiste à adopter des pratiques de sécurité rigoureuses à chaque étape du processus de développement et de déploiement des logiciels. Voici ces 5 principes clés pour garantir la sécurité des logiciels dès leur conception :
Modélisation des menaces
L’une de ces pratiques clés est la « modélisation des menaces » (ou Threat Modeling). Cette action permet d’anticiper les risques et les vulnérabilités latentes dès l’amorce même de la phase de conception.
Minimiser la surface d’attaque
Réduire la surface d’attaque constitue la seconde mesure importante de sécurité pour assurer la sécurité des systèmes informatiques. L’objectif, ici, est de limiter les opportunités pour les attaquants de trouver des failles et d’exploiter des vulnérabilités. On vise ainsi à limiter l’accès aux données et fonctionnalités sensibles.
Principe de moindre privilège (PoLP)
La troisième mesure de sécurité est la mise en place du « principe de moindre privilège » (ou Principle of least privilege). Ce dernier limite les droits d’accès des utilisateurs aux seules ressources nécessaires à l’exécution de leurs tâches.
Tests de validation dédiés à la sécurité
Afin d’améliorer la résilience face aux attaques potentielles, la quatrième mesure, la mise en place de tests de validation dédiés à la sécurité, permet, entre autres, de s’assurer du bon cloisonnement des fonctionnalités, et de l’assainissement des entrées de l’application.
Code sécurisé
Enfin, pour minimiser le risque d’erreurs pouvant introduire des vulnérabilités, il est recommandé d’écrire et de déployer un code sécurisé. Pour cela, il convient d’adopter de bonnes pratiques de développement. Ces réflexes s’acquièrent par des formations aux vulnérabilités les plus communes, référencées par la communauté OWASP.
Pour ce dernier point, les développeurs peuvent également utiliser des outils dédiés tels que les tests de sécurité d’application (AST : Application Security Testing). Ces outils leur permettent d’effectuer des vérifications approfondies du code. Mais ces AST sont loin d’être parfaits. L’expérience montre que ces scans remontent beaucoup (trop ?) de vulnérabilités. Dès lors, même en ne traitant que les plus critiques, il apparaît impossible de toutes les corriger.
Alors que faire si on a trop de vulnérabilités à traiter avec un budget ou un délai limité ? La réponse est le « Risk-based vulnerability management », une méthode qui permet d’évaluer et de réduire les risques liés aux vulnérabilités en tenant compte du contexte et de l’impact potentiel sur l’activité.
Évaluer les vulnérabilités pour mieux les prioriser
Vous avez accepté le postulat selon lequel vous vous avez trop de vulnérabilités – réelles ou pas – et pas assez de temps/budget pour tout corriger. Dès lors, il est nécessaire de les prioriser, mais selon quels critères ? Plusieurs métriques sont à votre disposition :
Le Common Vulnerability Scoring System (CVSS)
Le “Common Vulnerability Scoring System” est un système d’évaluation standardisé de la criticité des vulnérabilités, selon des critères objectifs et mesurables. Le score final est compris entre 0 et 10.
Au-delà de 9, la vulnérabilité est « critique » et il est communément admis qu’une vulnérabilité au-delà de 7 (« majeure / high ») devrait être corrigée dès que possible, voire ne pas aller en production.
Notons par ailleurs, qu’une version 4.0 du CVSS est en cours d’adoption depuis juin 2023.
Le score interne des outils
Les outils de détection des vulnérabilités identifient généralement des vulnérabilités bien référencées par leur identifiant CVE (Common Vulnerabilities and Exposures)[9]. Ainsi, la sévérité affichée est communément acceptée et fondée sur le CVSS que nous avons abordé précédemment.
Mais il arrive que certains outils identifient des vulnérabilités non référencées. Ainsi, les équipes de recherche et développement d’un outil SCA peuvent identifier une vulnérabilité « Zero-day » ; c’est-à-dire qui vient d’être découverte, et pour laquelle aucune mitigation n’est encore disponible.
Par exemple, l’outil BlackDuck (Synopsys) attribue des identifiants internes du type « BDSA-YYYY-XXX » ainsi qu’une sévérité interne en attendant une identification standard et reconnue.
La vulnérabilité Log4j identifiée par le SCA BlackDuck, avec son identifiant interne (BDSA) et standard (CVE)
De même, les outils SAST repèrent des vulnérabilités spécifiques au code, propre à l’environnement du projet. Par conséquent, ils ne peuvent hériter d’un identifiant ni même d’un score standard. Les outils utilisent donc leurs propres critères internes.
Par exemple, l’outil Fortify (Micro Focus) propose une notation sur 100, fondée sur la facilité de reproduction, les dommages possibles en cas d’exploitation, la facilité de localisation/découverte, etc.
Ces critères sont empiriques et peuvent parfois manquer de contexte. Il convient de les revoir avec les équipes de développement qui possèdent la connaissance de l’architecture logicielle.
Ces évaluations de vulnérabilités sont reconnues et éprouvées. Cependant, elles ne résoudront probablement pas vos enjeux de priorisation. En effet, trier les vulnérabilités ne diminuera pas leur volume. Il convient alors d’envisager une approche plus pragmatique : le « Risk Based Vulnerability Management ».
Risk Based Management : quel risque concret représente cette vulnérabilité ?
Outre la sévérité affichée d’une vulnérabilité, on peut s’interroger sur son exploitabilité. Dans les faits, est-elle actuellement et activement exploitée par des attaquants ou bien tombée dans l’oubli ?
La note EPSS
Le « EPSS », ou Exploit Prediction Scoring System[11], représente la probabilité qu’une vulnérabilité soit exploitée en ce moment. Cette note s’appuie entre autres sur l’existence d’un exploit dans la nature, et son éventuelle qualification de « zero day ».
Le rapport de PenTest
Un audit de sécurité externe peut être un outil d’aide à la priorisation. Pour cela, il nécessite une analyse affinée et pondérée par un auditeur externe. Ce dernier permettra de contextualiser la criticité de la vulnérabilité en fonction de la facilité d’exploitation, mais aussi de l’expertise requise à sa remédiation.
Mais la complexité et l’unicité des systèmes d’informations font qu’une même vulnérabilité n’aura pas forcément la même exploitabilité ni le même impact d’un environnement à l’autre. Ainsi, le risque intrinsèque à la vulnérabilité doit donc être pondéré par des critères spécifiques :
La criticité de l’actif cible
Les enjeux ne seront pas les mêmes selon que l’application vulnérable est critique pour des utilisateurs internes ou externes. De même, la criticité dépendra du volume de données traitées et du nombre d’utilisateurs. Dès lors, il conviendra de définir des engagements suffisants en termes de disponibilité et de reprise d’activité, mais aussi le délai maximum acceptable d’indisponibilité en cas d’attaque.
L’exposition de l’actif cible
Les dispositions à mettre en œuvre vont varier considérablement selon que l’application est exposée sur internet ou uniquement dans un réseau local d’entreprise. De même, son hébergement sur site nécessitera plus de moyens de redondance et de reprise que si elle est hébergée dans le cloud.
L’impact en cas d’attaque
Si la vulnérabilité est exploitée, les conséquences peuvent varier selon le risque propre au business de l’entreprise. Concrètement, il s’agit d’évaluer l’impact financier d’une exploitation de la vulnérabilité : perte de clientèle, amendes. Mais aussi l’impact non-financier : réputation, vol de données business et propriété intellectuelle.
Pour ne plus être submergé par les vulnérabilités : anticiper, évaluer, prioriser
Vous l’aurez compris, il est nécessaire de suivre des principes fondamentaux si l’on veut éviter de crouler sous les vulnérabilités.
Les bonnes pratiques de Security by Design représentent une base fondamentale qu’il faut structurer en amont et au plus tôt des projets.
De plus, il faut s’équiper d’outils d’analyse de code SAST et SCA. Toutefois, nous avons vu que ces outils, bien que nécessaires, ne sont probablement pas suffisants pour évaluer les vulnérabilités des applications. Car en réalité, le nombre de vulnérabilités reste souvent trop important pour pouvoir tout adresser et encore moins tout corriger.
Ainsi, Il est recommandé d’inclure une évaluation du risque relatif à chaque vulnérabilité afin de mesurer sa diffusion et son exploitabilité. En pratique, chaque risque doit être pondéré au regard des actifs de l’organisation, et des impacts éventuels sur le business.
Finalement, vous pourrez ainsi prioriser les efforts des équipes en fonction du risque réel. Vous permettrez alors aux équipes IT de se concentrer sur la véritable valeur ajoutée des fonctionnalités de leurs applications, tout en livrant des produits plus sécurisés.
A suivre : « DAST, SAST et SCA : les outils dédiés aux tests de sécurité d’applications »