La plupart des programmes de sécurité applicative savent dire ce qu’ils ont fait au dernier trimestre. Bien moins savent dire si cela a fonctionné. Le stream Measure and Improve d’OWASP SAMM existe pour combler cet écart.
Cet article est un guide communautaire pour le stream Measure and Improve de la practice Strategy and Metrics de SAMM. L’entrée OpenCRE correspondante est Steer the secure software development program. Les indicateurs ci-dessous portent sur le développement logiciel dans les équipes R&D. Les indicateurs de sécurité opérationnelle, comme le niveau de correctifs des serveurs de production ou le taux de clics lors de campagnes de phishing, sont un autre sujet.
Ce qui fait un bon indicateur
Selon SAMM, ces indicateurs servent à mesurer l’efficacité et l’efficience de votre programme de sécurité applicative. Gardez-le en tête en construisant la liste. Chaque indicateur doit apprendre à l’équipe de sécurité applicative quelque chose dont elle a besoin pour atteindre ses propres objectifs. Un indicateur dont personne ne tient compte n’est qu’une charge.
Chaque indicateur doit aussi :
- se mesurer chaque fois de la même façon, pour que les tendances aient un sens
- coûter peu à collecter, idéalement de façon automatique à partir des outils que vous utilisez déjà
- s’exprimer en nombre ou en pourcentage, avec une unité claire
Documentez chaque indicateur avec son nom, sa formule, son unité, sa source de données, sa fréquence de collecte et son responsable. Cette simple ligne de documentation évite plus tard la plupart des débats sur les chiffres.
Trois catégories : effort, résultat et environnement
Au niveau de maturité 1, l’équipe de sécurité recueille des indicateurs dans les trois catégories définies par SAMM : effort, résultat et environnement. L’essentiel est de comprendre comment les indicateurs d’effort et d’environnement influencent les indicateurs de résultat.
C’est aussi ce lien que vous présentez à la direction. Les dirigeants s’intéressent aux résultats, mais ils ne peuvent investir que dans l’effort. Si vous montrez quels efforts font bouger quels résultats, les décisions d’investissement deviennent bien plus faciles à justifier.
La carte ci-dessous présente des exemples d’indicateurs par catégorie, avec des liens qui montrent comment ils s’influencent. Servez-vous-en comme point de départ et adaptez-la aux objectifs de votre propre programme.
Indicateurs d’effort
Les indicateurs d’effort mesurent la quantité de travail consacrée aux activités de sécurité. Ils comptent surtout des activités qui ne sont pas des résultats en soi, mais qui aident à en obtenir.
Exemples :
- nombre de formations à la sécurité, ou nombre total d’heures de formation
- nombre d’événements externes sur la sécurité suivis, comme des ateliers, conférences et rencontres communautaires
- nombre de communications internes sur la sécurité
- temps consacré aux revues de code sécurité
- nombre de revues d’architecture centrées sur la sécurité
- nombre de sessions de threat modeling
- nombre de tests d’intrusion
- nombre de sessions de revue des exigences de sécurité dans les demandes fonctionnelles
- nombre de défauts de sécurité clôturés dans votre outil de suivi, comme Jira
- nombre de constats clôturés dans les outils SCA, SAST et DAST sur une période donnée
- budget consacré aux outils et licences de sécurité
- nombre d’évaluations OWASP SAMM réalisées
Indicateurs de résultat
Les indicateurs de résultat mesurent l’efficacité de l’effort de sécurité. Au niveau de maturité 2 de ce stream, vous choisissez les plus importants comme KPI principaux de votre programme de sécurité applicative et leur fixez des cibles.
Exemples :
- couverture de la formation à la sécurité : personnes formées divisées par les personnes qui devraient l’être
- sensibilisation à la sécurité : scores moyens aux quiz ou enquêtes après formation
- nombre total de security champions
- couverture par les security champions : équipes ou produits avec au moins un champion divisés par l’ensemble des équipes ou produits
- flux d’incidents de sécurité : nouveaux incidents signalés sur une période donnée
- coût par incident, en argent ou en jours-homme
- délai moyen de correction, ou de clôture d’un incident
- couverture des outils : applications ou dépôts analysés par SCA, SAST et DAST divisés par ceux qui devraient l’être
- constats SCA ouverts, ou score de risque total des dépendances tierces
- vulnérabilités critiques de plus de 90 jours dans des composants tiers
- constats de sécurité ouverts issus du SAST
- défauts de sécurité ouverts dans votre outil de suivi
- niveaux de service : délai moyen de correction des défauts et incidents de sécurité, et leur coût total en jours-homme
- couverture des évaluations SAMM : périmètres avec une évaluation récente divisés par l’ensemble des périmètres
Indicateurs d’environnement
Les indicateurs d’environnement décrivent le contexte dans lequel se déroule le travail de sécurité. Ils aident à comprendre l’étendue et la complexité du programme. Ils n’ont pas besoin d’être liés à des outils ou activités de sécurité, mais vous en avez besoin comme données d’entrée des indicateurs de résultat, surtout comme dénominateurs des taux de couverture.
Exemples :
- nombre de périmètres de l’organisation utilisés pour les évaluations SAMM
- nombre total de produits ou d’applications
- nombre de produits ou d’applications qui devraient être couverts par le DAST
- nombre de composants tiers utilisés
- nombre total d’équipes de développement, d’assurance qualité et d’exploitation, et de personnes qui les composent
- budget disponible pour les événements externes et la formation en sécurité
- budget disponible pour les outils et licences de sécurité
- nombre de responsables sécurité
Comment les catégories se relient
Quelques relations de la carte montrent comment cela fonctionne en pratique :
- Plus d’heures de formation devraient augmenter la couverture de formation et les scores de sensibilisation, et faire croître le nombre de security champions.
- Les sessions de threat modeling, les revues d’architecture et les tests d’intrusion devraient réduire le flux d’incidents, le coût par incident et le délai de correction.
- Clôturer des constats SCA, SAST et DAST réduit le nombre de constats ouverts, tant que les nouveaux n’arrivent pas plus vite.
- Le budget consacré aux outils augmente la couverture SCA, SAST et DAST, mesurée par rapport au nombre d’applications issu de vos indicateurs d’environnement.
- Réaliser des évaluations SAMM augmente la couverture des évaluations, mesurée par rapport au nombre de périmètres.
Quand un résultat ne bouge pas alors que l’effort a augmenté, cela mérite une discussion. L’effort vise peut-être la mauvaise cible, ou l’environnement a grandi plus vite que le programme.
Indicateurs pour préparer le CRA
Si vous fabriquez des produits comportant des éléments numériques pour le marché de l’UE, le Cyber Resilience Act donne à certains indicateurs de résultat une portée juridique. Ceux-ci méritent une place dans votre liste :
- produits avec une SBOM à jour divisés par l’ensemble des produits concernés
- produits avec une période de support définie et publiée
- délai médian de correction des vulnérabilités critiques dans les versions de produits maintenues
- vulnérabilités critiques dans des composants tiers sans correctif ni plan d’atténuation
- produits couverts par une politique de divulgation coordonnée des vulnérabilités publiée
- délai entre la connaissance d’une vulnérabilité activement exploitée et l’alerte précoce sous 24 heures, mesuré lors d’exercices avant d’en avoir besoin pour de vrai
Notre guide du CRA pour les PME explique les obligations qui les sous-tendent, et OWASP Dependency-Track peut fournir automatiquement plusieurs des chiffres sur les SBOM et les vulnérabilités tierces.
Des indicateurs aux KPI
Définir et documenter vos indicateurs Measure and Improve est l’étape qui précède le niveau de maturité 2, où vous choisissez les KPI parmi vos indicateurs de résultat et leur fixez des cibles. Commencez petit. Cinq indicateurs collectés de façon fiable chaque mois valent mieux que trente collectés une seule fois.
Pour un regard indépendant sur l’état de votre programme, notre SSDLC Maturity Assessment évalue vos pratiques actuelles avec OWASP SAMM et établit une feuille de route d’amélioration.