Analyse et rapport des données de test de sécurité

Objectifs des métriques et mesures des tests de sécurité

La définition des objectifs des métriques et mesures des tests de sécurité est une condition préalable à l'utilisation des données de test de sécurité pour les processus d'analyse et de gestion des risques. Par exemple, une mesure, telle que le nombre total de vulnérabilités détectées lors des tests de sécurité, peut quantifier la posture de sécurité de l'application. Ces mesures aident également à identifier les objectifs de sécurité pour les tests de sécurité des logiciels, par exemple, réduire le nombre de vulnérabilités à un nombre minimum acceptable avant le déploiement de l'application en production.

Un autre objectif gérable pourrait être de comparer la posture de sécurité de l'application à une base de référence pour évaluer les améliorations des processus de sécurité des applications. Par exemple, la base de référence des métriques de sécurité peut consister en une application qui n'a été testée qu'avec des tests d'intrusion. Les données de sécurité obtenues à partir d'une application qui a également été testée en matière de sécurité pendant le codage devraient montrer une amélioration (par exemple, moins de vulnérabilités) par rapport à la base de référence.

Dans les tests logiciels traditionnels, le nombre de défauts logiciels, tels que les bogues trouvés dans une application, peut fournir une mesure de la qualité du logiciel. De même, les tests de sécurité peuvent fournir une mesure de la sécurité des logiciels. Du point de vue de la gestion des défauts et des rapports, les tests de qualité et de sécurité des logiciels peuvent utiliser des catégorisations similaires pour les causes profondes et les efforts de correction des défauts. Du point de vue de la cause profonde, un défaut de sécurité peut être dû à une erreur de conception (par exemple, des failles de sécurité) ou à une erreur de codage (par exemple, un bogue de sécurité). Du point de vue de l'effort requis pour corriger un défaut, les défauts de sécurité et de qualité peuvent être mesurés en termes d'heures de développement pour mettre en oeuvre le correctif, les outils et les ressources nécessaires, et le coût de mise en oeuvre du correctif.

Une caractéristique des données de test de sécurité, par rapport aux données de qualité, est la catégorisation en termes de menace, d'exposition de la vulnérabilité et d'impact potentiel posé par la vulnérabilité pour déterminer le risque. Tester les applications pour la sécurité consiste à gérer les risques techniques pour s'assurer que les contre-mesures de l'application atteignent des niveaux acceptables. Pour cette raison, les données de test de sécurité doivent prendre en charge la stratégie de risque de sécurité à des points de contrôle critiques pendant le SDLC. Par exemple, les vulnérabilités trouvées dans le code source avec l'analyse du code source représentent une mesure initiale du risque. Une mesure du risque (par exemple, élevé, moyen, faible) pour la vulnérabilité peut être calculée en déterminant les facteurs d'exposition et de probabilité, et en validant la vulnérabilité avec des tests d'intrusion. Les mesures de risque associées aux vulnérabilités trouvées avec les tests de sécurité permettent à la direction de l'entreprise de prendre des décisions de gestion des risques, par exemple de décider si les risques peuvent être acceptés, atténués ou transférés à différents niveaux au sein de l'organisation (par exemple, les risques commerciaux et techniques).

Lors de l'évaluation de la posture de sécurité d'une application, il est important de prendre en considération certains facteurs, tels que la taille de l'application en cours de développement. Il a été statistiquement prouvé que la taille de l'application est liée au nombre de problèmes détectés dans l'application pendant les tests. Etant donné que les tests réduisent les problèmes, il est logique que les applications de plus grande taille soient testées plus souvent que les applications de plus petite taille.

Lorsque les tests de sécurité sont effectués en plusieurs phases du SDLC, les données de test peuvent prouver la capacité des tests de sécurité à détecter les vulnérabilités dès qu'elles sont introduites. Les données de test peuvent également prouver l'efficacité de la suppression des vulnérabilités en mettant en oeuvre des contre-mesures à différents points de contrôle du SDLC. Une mesure de ce type est également définie comme "mesures de confinement" et fournit une mesure de la capacité d'une évaluation de sécurité effectuée à chaque phase du processus de développement à maintenir la sécurité dans chaque phase. Ces mesures de confinement sont également un facteur essentiel pour réduire le coût de correction des vulnérabilités. Il est moins coûteux de traiter les vulnérabilités dans la même phase du SDLC qu'elles sont trouvées, plutôt que de les corriger plus tard dans une autre phase.

Les métriques de test de sécurité peuvent prendre en charge l'analyse des risques de sécurité, des coûts et de la gestion des défauts lorsqu'elles sont associées à des objectifs tangibles et chronométrés tels que :

• Réduire le nombre global de vulnérabilités de 30 %.
• Corriger les problèmes de sécurité avant une certaine date limite (par exemple, avant la version bêta).

Les données de test de sécurité peuvent être absolues, telles que le nombre de vulnérabilités détectées lors de la revue manuelle du code, ainsi que comparatives, telles que le nombre de vulnérabilités détectées lors des revues de code par rapport aux tests d'intrusion. Pour répondre aux questions sur la qualité du processus de sécurité, il est important de déterminer une base de référence pour ce qui pourrait être considéré comme acceptable et bon.

Les données de test de sécurité peuvent également prendre en charge des objectifs spécifiques de l'analyse de sécurité. Ces objectifs peuvent être la conformité aux réglementations de sécurité et aux normes de sécurité de l'information, la gestion des processus de sécurité, l'identification des causes profondes de la sécurité et l'amélioration des processus, et l'analyse coûts-avantages de la sécurité.

Lorsque des données de test de sécurité sont signalées, elles doivent fournir des mesures pour prendre en charge l'analyse. La portée de l'analyse est l'interprétation des données de test pour trouver des indices sur la sécurité du logiciel en cours de production, ainsi que sur l'efficacité du processus.

Voici quelques exemples d'indices pris en charge par les données de test de sécurité :

• Les vulnérabilités sont-elles réduites à un niveau acceptable pour la publication ?
• Comment la qualité de la sécurité de ce produit se compare-t-elle à des produits logiciels similaires ?
• Toutes les exigences des tests de sécurité sont-elles respectées ?
• Quelles sont les principales causes profondes des problèmes de sécurité ?
• Combien y a-t-il de failles de sécurité par rapport aux bogues de sécurité ?
• Quelle activité de sécurité est la plus efficace pour trouver des vulnérabilités ?
• Quelle équipe est la plus productive pour corriger les défauts et les vulnérabilités de sécurité ?
• Quel pourcentage des vulnérabilités globales sont à haut risque ?
• Quels outils sont les plus efficaces pour détecter les vulnérabilités de sécurité ?
• Quel type de tests de sécurité est le plus efficace pour trouver des vulnérabilités (par exemple, tests en boîte blanche par rapport aux tests en boîte noire) ?
• Combien de problèmes de sécurité sont détectés lors des revues de code sécurisé ?
• Combien de problèmes de sécurité sont détectés lors des revues de conception sécurisée ?

Afin de porter un jugement éclairé à l'aide des données de test, il est important d'avoir une bonne compréhension du processus de test ainsi que des outils de test. Une taxonomie des outils doit être adoptée pour décider quels outils de sécurité utiliser. Les outils de sécurité peuvent être qualifiés de bons pour trouver des vulnérabilités courantes et connues, lorsqu'ils ciblent différents artefacts.

Il est important de noter que les problèmes de sécurité inconnus ne sont pas testés. Le fait qu'un test de sécurité soit exempt de problèmes ne signifie pas que le logiciel ou l'application est bon.

Même les outils d'automatisation les plus sophistiqués ne sont pas à la hauteur d'un testeur de sécurité expérimenté. Le simple fait de se fier aux résultats positifs des tests des outils automatisés donnera aux professionnels de la sécurité un faux sentiment de sécurité. En règle générale, plus les testeurs de sécurité sont expérimentés avec la méthodologie de test de sécurité et les outils de test, meilleurs seront les résultats du test et de l'analyse de sécurité. Il est important que les responsables qui investissent dans des outils de test de sécurité envisagent également d'investir dans l'embauche de ressources humaines qualifiées, ainsi que dans la formation aux tests de sécurité.

Exigences en matière de rapports

La posture de sécurité d'une application peut être caractérisée du point de vue de l'effet, tel que le nombre de vulnérabilités et le niveau de risque des vulnérabilités, ainsi que du point de vue de la cause ou de l'origine, telle que les erreurs de codage, les failles architecturales et les problèmes de configuration.

Les vulnérabilités peuvent être classées selon différents critères. La métrique de gravité des vulnérabilités la plus couramment utilisée est le Common Vulnerability Scoring System (CVSS), une norme maintenue par le Forum of Incident Response and Security Teams (FIRST).

Lors de la communication des données de test de sécurité, la meilleure pratique consiste à inclure les informations suivantes :

• une catégorisation de chaque vulnérabilité par type ;
• la menace de sécurité à laquelle chaque problème est exposé ;
• la cause profonde de chaque problème de sécurité, tel que le bogue ou la faille ;
• chaque technique de test utilisée pour trouver les problèmes ;
• la remédiation, ou contre-mesure, pour chaque vulnérabilité ; et
• le niveau de gravité de chaque vulnérabilité (par exemple, élevé, moyen, faible ou score CVSS).

En décrivant la menace de sécurité, il sera possible de comprendre si et pourquoi le contrôle d'atténuation est inefficace pour atténuer la menace.

Le signalement de la cause profonde du problème peut aider à identifier ce qui doit être corrigé. Dans le cas des tests en boîte blanche, par exemple, la cause profonde de la vulnérabilité de la sécurité logicielle sera le code source incriminé.

Une fois les problèmes signalés, il est également important de fournir des conseils au développeur de logiciels sur la façon de retester et de trouver la vulnérabilité. Cela peut impliquer l'utilisation d'une technique de test en boîte blanche (par exemple, une revue de code de sécurité avec un analyseur de code statique) pour déterminer si le code est vulnérable. Si une vulnérabilité peut être trouvée via un test d'intrusion en boîte noire, le rapport de test doit également fournir des informations sur la façon de valider l'exposition de la vulnérabilité au frontend (par exemple, le client).

Les informations sur la façon de corriger la vulnérabilité doivent être suffisamment détaillées pour qu'un développeur puisse mettre en oeuvre un correctif. Elles doivent fournir des exemples de codage sécurisé, des modifications de configuration et fournir des références adéquates.

Enfin, le niveau de gravité contribue au calcul du niveau de risque et aide à hiérarchiser les efforts de remédiation. En règle générale, l'attribution d'un niveau de risque à la vulnérabilité implique une analyse externe des risques basée sur des facteurs tels que l'impact et l'exposition.

Cas d'utilisation

Pour que les métriques de test de sécurité soient utiles, elles doivent apporter une valeur ajoutée aux parties prenantes des données de test de sécurité de l'organisation. Les parties prenantes peuvent inclure les chefs de projet, les développeurs, les bureaux de sécurité de l'information, les auditeurs et les directeurs des systèmes d'information. La valeur peut être exprimée en termes de cas d'utilisation que chaque partie prenante du projet a, en termes de rôle et de responsabilité.

Les développeurs de logiciels examinent les données de test de sécurité pour montrer que les logiciels sont codés de manière sécurisée et efficace. Cela leur permet de justifier l'utilisation d'outils d'analyse du code source, le respect des normes de codage sécurisé et la participation à une formation sur la sécurité des logiciels.

Les chefs de projet recherchent des données qui leur permettent de gérer et d'utiliser avec succès les activités et les ressources de test de sécurité conformément au plan du projet. Pour les chefs de projet, les données de test de sécurité peuvent montrer que les projets sont dans les délais et progressent vers les dates de livraison, et qu'ils s'améliorent pendant les tests.

Les données de test de sécurité aident également le cas d'utilisation des tests de sécurité si l'initiative vient des responsables de la sécurité de l'information (RSSI). Par exemple, elles peuvent fournir la preuve que les tests de sécurité pendant le SDLC n'ont pas d'impact sur la livraison du projet, mais réduisent plutôt la charge de travail globale nécessaire pour traiter les vulnérabilités plus tard en production.

Pour les auditeurs de conformité, les mesures de test de sécurité fournissent un niveau d'assurance de la sécurité logicielle et la certitude que la conformité aux normes de sécurité est traitée par le biais des processus de revue de sécurité au sein de l'organisation.

Enfin, les directeurs des systèmes d'information (DSI) et les responsables de la sécurité des systèmes d'information (RSSI), qui sont responsables du budget qui doit être alloué aux ressources de sécurité, recherchent la dérivation d'une analyse coûts-avantages à partir des données de test de sécurité. Cela leur permet de prendre des décisions éclairées sur les activités et les outils de sécurité dans lesquels investir. L'une des mesures qui prend en charge une telle analyse est le retour sur investissement (ROI) en matière de sécurité. Pour dériver de telles mesures à partir des données de test de sécurité, il est important de quantifier le différentiel entre le risque, dû à l'exposition des vulnérabilités, et l'efficacité des tests de sécurité dans l'atténuation du risque de sécurité, puis de factoriser cet écart avec le coût de l'activité de test de sécurité ou des outils de test adoptés.