Dérivation des exigences de test de sécurité

Introduction

Pour avoir un programme de test réussi, il faut connaître les objectifs de test. Ces objectifs sont spécifiés par les exigences de sécurité. Cette section explique en détail comment documenter les exigences pour les tests de sécurité en les dérivant des normes et réglementations applicables, des exigences applicatives positives (spécifiant ce que l'application est censée faire) et des exigences applicatives négatives (spécifiant ce que l'application ne doit pas faire). Elle explique également comment les exigences de sécurité pilotent efficacement les tests de sécurité pendant le SDLC et comment les données de test de sécurité peuvent être utilisées pour gérer efficacement les risques de sécurité des logiciels.

Objectifs des tests

L'un des objectifs des tests de sécurité est de valider que les contrôles de sécurité fonctionnent comme prévu. Ceci est documenté via des exigences de sécurité qui décrivent la fonctionnalité du contrôle de sécurité. A un niveau élevé, cela signifie prouver la confidentialité, l'intégrité et la disponibilité des données ainsi que du service. L'autre objectif est de valider que les contrôles de sécurité sont mis en oeuvre avec peu ou pas de vulnérabilités. Il s'agit de vulnérabilités courantes, telles que le OWASP Top Ten, ainsi que de vulnérabilités qui ont été précédemment identifiées avec des évaluations de sécurité pendant le SDLC, telles que la modélisation des menaces, l'analyse du code source et les tests d'intrusion.

Documentation des exigences de sécurité

La première étape de la documentation des exigences de sécurité est de comprendre les exigences métier. Un document d'exigences métier peut fournir des informations initiales de haut niveau sur la fonctionnalité attendue de l'application. Par exemple, le but principal d'une application peut être de fournir des services financiers aux clients ou de permettre l'achat de biens à partir d'un catalogue en ligne. Une section de sécurité des exigences métier doit souligner la nécessité de protéger les données des clients ainsi que de se conformer à la documentation de sécurité applicable telle que les réglementations, les normes et les politiques.

Une liste de contrôle générale des réglementations, normes et politiques applicables est une bonne analyse préliminaire de la conformité en matière de sécurité pour les applications web. Par exemple, les réglementations de conformité peuvent être identifiées en vérifiant les informations sur le secteur d'activité et le pays ou l'Etat où l'application fonctionnera. Certaines de ces directives et réglementations de conformité peuvent se traduire par des exigences techniques spécifiques pour les contrôles de sécurité. Par exemple, dans le cas des applications financières, la conformité avec le Federal Financial Institutions Examination Council (FFIEC) Cybersecurity Assessment Tool & Documentation exige que les institutions financières mettent en oeuvre des applications qui atténuent les risques d'authentification faible avec des contrôles de sécurité multicouches et une authentification multifacteur.

Les normes industrielles applicables en matière de sécurité doivent également être saisies dans la liste de contrôle générale des exigences de sécurité. Par exemple, dans le cas des applications qui traitent des données de carte de crédit des clients, la conformité avec la norme de sécurité des données (DSS) du PCI Security Standards Council interdit le stockage des données PIN et CVV2 et exige que le commerçant protège les données de la bande magnétique en stockage et en transmission avec un cryptage et à l'affichage par masquage. Ces exigences de sécurité PCI DSS pourraient être validées par une analyse du code source.

Une autre section de la liste de contrôle doit faire respecter les exigences générales de conformité avec les normes et politiques de sécurité de l'information de l'organisation. Du point de vue des exigences fonctionnelles, les exigences relatives au contrôle de sécurité doivent correspondre à une section spécifique des normes de sécurité de l'information. Un exemple d'une telle exigence peut être : "une complexité de mot de passe de dix caractères alphanumériques doit être appliquée par les contrôles d'authentification utilisés par l'application". Lorsque les exigences de sécurité correspondent aux règles de conformité, un test de sécurité peut valider l'exposition aux risques de conformité. Si une violation des normes et politiques de sécurité de l'information est constatée, cela entraînera un risque qui peut être documenté et que l'entreprise doit gérer ou traiter. Etant donné que ces exigences de conformité en matière de sécurité sont exécutoires, elles doivent être bien documentées et validées par des tests de sécurité.

Validation des exigences de sécurité

Du point de vue de la fonctionnalité, la validation des exigences de sécurité est l'objectif principal des tests de sécurité. Du point de vue de la gestion des risques, la validation des exigences de sécurité est l'objectif des évaluations de la sécurité de l'information. A un niveau élevé, l'objectif principal des évaluations de la sécurité de l'information est l'identification des lacunes dans les contrôles de sécurité, telles que l'absence de contrôles de base d'authentification, d'autorisation ou de cryptage. Plus en détail, l'objectif de l'évaluation de la sécurité est l'analyse des risques, telle que l'identification des faiblesses potentielles dans les contrôles de sécurité qui garantissent la confidentialité, l'intégrité et la disponibilité des données. Par exemple, lorsque l'application traite des informations personnelles identifiables (PII) et des données sensibles, l'exigence de sécurité à valider est la conformité avec la politique de sécurité de l'information de l'entreprise exigeant le cryptage de ces données en transit et en stockage. En supposant que le cryptage est utilisé pour protéger les données, les algorithmes de cryptage et les longueurs de clé doivent être conformes aux normes de cryptage de l'organisation. Ceux-ci peuvent exiger que seuls certains algorithmes et longueurs de clé soient utilisés. Par exemple, une exigence de sécurité qui peut être testée en matière de sécurité consiste à vérifier que seuls les chiffrements autorisés sont utilisés (par exemple, SHA-256, RSA, AES) avec des longueurs de clé minimales autorisées (par exemple, plus de 128 bits pour le cryptage symétrique et plus de 1024 pour le cryptage asymétrique).

Du point de vue de l'évaluation de la sécurité, les exigences de sécurité peuvent être validées à différentes phases du SDLC en utilisant différents artefacts et méthodologies de test. Par exemple, la modélisation des menaces se concentre sur l'identification des failles de sécurité lors de la conception ; l'analyse et les revues de code sécurisé se concentrent sur l'identification des problèmes de sécurité dans le code source pendant le développement ; et les tests d'intrusion se concentrent sur l'identification des vulnérabilités dans l'application pendant les tests ou la validation.

Les problèmes de sécurité identifiés au début du SDLC peuvent être documentés dans un plan de test afin qu'ils puissent être validés ultérieurement avec des tests de sécurité. En combinant les résultats de différentes techniques de test, il est possible de dériver de meilleurs cas de test de sécurité et d'augmenter le niveau d'assurance des exigences de sécurité. Par exemple, il est possible de distinguer les vraies vulnérabilités de celles qui ne sont pas exploitables lorsque les résultats des tests d'intrusion et de l'analyse du code source sont combinés. En considérant le test de sécurité pour une vulnérabilité d'injection SQL, par exemple, un test en boîte noire peut d'abord impliquer une analyse de l'application pour identifier la vulnérabilité. La première preuve d'une vulnérabilité d'injection SQL potentielle qui peut être validée est la génération d'une exception SQL. Une validation supplémentaire de la vulnérabilité SQL peut impliquer l'injection manuelle de vecteurs d'attaque pour modifier la grammaire de la requête SQL pour un exploit de divulgation d'informations. Cela peut impliquer beaucoup d'analyses par essais et erreurs avant que la requête malveillante ne soit exécutée. En supposant que le testeur dispose du code source, il peut directement apprendre de l'analyse du code source comment construire le vecteur d'attaque SQL qui exploitera avec succès la vulnérabilité (par exemple, exécuter une requête malveillante renvoyant des données confidentielles à un utilisateur non autorisé). Cela peut accélérer la validation de la vulnérabilité SQL.

Taxonomies des menaces et des contre-mesures

Une classification des menaces et des contre-mesures, qui prend en considération les causes profondes des vulnérabilités, est le facteur essentiel pour vérifier que les contrôles de sécurité sont conçus, codés et construits pour atténuer l'impact de l'exposition à de telles vulnérabilités. Dans le cas des applications web, l'exposition des contrôles de sécurité aux vulnérabilités courantes, telles que le Top Ten OWASP, peut être un bon point de départ pour dériver les exigences de sécurité générales. Les listes de contrôle du guide de test OWASP sont une ressource utile pour guider les testeurs à travers des vulnérabilités spécifiques et des tests de validation.

L'objectif d'une catégorisation des menaces et des contre-mesures est de définir les exigences de sécurité en termes de menaces et de cause profonde de la vulnérabilité. Une menace peut être catégorisée en utilisant STRIDE, un acronyme pour Spoofing (usurpation d'identité), Tampering (falsification), Repudiation (répudiation), Information disclosure (divulgation d'informations), Denial of service (déni de service) et Elevation of privilege (élévation de privilèges). La cause profonde peut être classée comme une faille de sécurité dans la conception, un bogue de sécurité dans le codage ou un problème dû à une configuration non sécurisée. Par exemple, la cause profonde d'une vulnérabilité d'authentification faible peut être l'absence d'authentification mutuelle lorsque les données traversent une limite de confiance entre les niveaux client et serveur de l'application. Une exigence de sécurité qui capture la menace de non-répudiation lors d'une revue de conception d'architecture permet de documenter l'exigence de la contre-mesure (par exemple, l'authentification mutuelle) qui peut être validée ultérieurement avec des tests de sécurité.

Une catégorisation des menaces et des contre-mesures pour les vulnérabilités peut également être utilisée pour documenter les exigences de sécurité pour le codage sécurisé, telles que les normes de codage sécurisé. Un exemple d'erreur de codage courante dans les contrôles d'authentification consiste à appliquer une fonction de hachage pour crypter un mot de passe, sans appliquer de graine à la valeur. Du point de vue du codage sécurisé, il s'agit d'une vulnérabilité qui affecte le cryptage utilisé pour l'authentification avec une cause profonde de vulnérabilité dans une erreur de codage. Etant donné que la cause profonde est un codage non sécurisé, l'exigence de sécurité peut être documentée dans les normes de codage sécurisé et validée par des revues de code sécurisé pendant la phase de développement du SDLC.

Tests de sécurité et analyse des risques

Les exigences de sécurité doivent prendre en considération la gravité des vulnérabilités pour soutenir une stratégie d'atténuation des risques. En supposant que l'organisation maintienne un référentiel des vulnérabilités trouvées dans les applications (c'est-à-dire une base de connaissances des vulnérabilités), les problèmes de sécurité peuvent être signalés par type, problème, atténuation, cause profonde et mappés aux applications où ils sont trouvés. Une telle base de connaissances sur les vulnérabilités peut également être utilisée pour établir des mesures afin d'analyser l'efficacité des tests de sécurité tout au long du SDLC.

Par exemple, considérons un problème de validation d'entrée, tel qu'une injection SQL, qui a été identifié via une analyse du code source et signalé avec une cause profonde d'erreur de codage et un type de vulnérabilité de validation d'entrée. L'exposition d'une telle vulnérabilité peut être évaluée via un test d'intrusion, en sondant les champs d'entrée avec plusieurs vecteurs d'attaque par injection SQL. Ce test peut valider que les caractères spéciaux sont filtrés avant d'atteindre la base de données et atténuer la vulnérabilité. En combinant les résultats de l'analyse du code source et des tests d'intrusion, il est possible de déterminer la probabilité et l'exposition de la vulnérabilité et de calculer le niveau de risque de la vulnérabilité. En signalant les niveaux de risque de vulnérabilité dans les résultats (par exemple, le rapport de test), il est possible de décider de la stratégie d'atténuation. Par exemple, les vulnérabilités à risque élevé et moyen peuvent être prioritaires pour la remédiation, tandis que les vulnérabilités à faible risque peuvent être corrigées dans les versions futures.

En considérant les scénarios de menace d'exploitation des vulnérabilités courantes, il est possible d'identifier les risques potentiels pour lesquels le contrôle de sécurité de l'application doit être testé. Par exemple, les vulnérabilités du Top Ten OWASP peuvent être mappées à des attaques telles que le phishing, les violations de la vie privée, le vol d'identité, la compromission du système, la modification ou la destruction de données, les pertes financières et la perte de réputation. Ces problèmes doivent être documentés dans le cadre des scénarios de menace. En pensant en termes de menaces et de vulnérabilités, il est possible de concevoir une batterie de tests qui simulent de tels scénarios d'attaque. Idéalement, la base de connaissances sur les vulnérabilités de l'organisation peut être utilisée pour dériver des cas de test axés sur les risques de sécurité afin de valider les scénarios d'attaque les plus probables. Par exemple, si le vol d'identité est considéré comme un risque élevé, les scénarios de test négatifs doivent valider l'atténuation des impacts découlant de l'exploitation des vulnérabilités dans l'authentification, les contrôles cryptographiques, la validation des entrées et les contrôles d'autorisation.

Dérivation des exigences de test fonctionnelles et non fonctionnelles

Exigences de sécurité fonctionnelles

Du point de vue des exigences de sécurité fonctionnelles, les normes, politiques et réglementations applicables déterminent à la fois le besoin d'un type de contrôle de sécurité ainsi que la fonctionnalité du contrôle. Ces exigences sont également appelées "exigences positives", car elles énoncent la fonctionnalité attendue qui peut être validée par des tests de sécurité. Des exemples d'exigences positives sont : "l'application verrouillera l'utilisateur après six tentatives de connexion infructueuses" ou "les mots de passe doivent comporter au moins dix caractères alphanumériques". La validation des exigences positives consiste à affirmer la fonctionnalité attendue et peut être testée en recréant les conditions de test et en exécutant le test selon des entrées prédéfinies. Les résultats sont ensuite affichés sous forme de condition d'échec ou de réussite.

Afin de valider les exigences de sécurité avec des tests de sécurité, les exigences de sécurité doivent être axées sur les fonctions. Elles doivent mettre en évidence la fonctionnalité attendue (le quoi) et impliquer la mise en oeuvre (le comment). Des exemples d'exigences de conception de sécurité de haut niveau pour l'authentification peuvent être :

• Protéger les informations d'identification de l'utilisateur ou les secrets partagés en transit et en stockage.
• Masquer toute donnée confidentielle à l'affichage (par exemple, mots de passe, comptes).
• Verrouiller le compte utilisateur après un certain nombre de tentatives de connexion infructueuses.
• Ne pas afficher d'erreurs de validation spécifiques à l'utilisateur à la suite d'une connexion infructueuse.
• Autoriser uniquement les mots de passe alphanumériques, inclure des caractères spéciaux et avoir une longueur minimale de dix caractères, afin de limiter la surface d'attaque.
• Autoriser la fonctionnalité de changement de mot de passe uniquement aux utilisateurs authentifiés en validant l'ancien mot de passe, le nouveau mot de passe et la réponse de l'utilisateur à la question de défi, afin d'empêcher le forçage brutal d'un mot de passe via le changement de mot de passe.
• Le formulaire de réinitialisation du mot de passe doit valider le nom d'utilisateur de l'utilisateur et l'adresse e-mail enregistrée de l'utilisateur avant d'envoyer le mot de passe temporaire à l'utilisateur par e-mail. Le mot de passe temporaire émis doit être un mot de passe à usage unique. Un lien vers la page web de réinitialisation du mot de passe sera envoyé à l'utilisateur. La page web de réinitialisation du mot de passe doit valider le mot de passe temporaire de l'utilisateur, le nouveau mot de passe, ainsi que la réponse de l'utilisateur à la question de défi.

Exigences de sécurité axées sur les risques

Les tests de sécurité doivent également être axés sur les risques. Ils doivent valider l'application pour un comportement inattendu, ou des exigences négatives.

Exemples d'exigences négatives :

• L'application ne doit pas permettre la modification ou la destruction des données.
• L'application ne doit pas être compromise ou utilisée à mauvais escient pour des transactions financières non autorisées par un utilisateur malveillant.

Les exigences négatives sont plus difficiles à tester, car il n'y a pas de comportement attendu à rechercher. La recherche d'un comportement attendu pour répondre aux exigences ci-dessus pourrait exiger d'un analyste des menaces qu'il propose de manière irréaliste des conditions d'entrée, des causes et des effets imprévisibles. Par conséquent, les tests de sécurité doivent être pilotés par l'analyse des risques et la modélisation des menaces. La clé est de documenter les scénarios de menace et la fonctionnalité de la contre-mesure en tant que facteur d'atténuation d'une menace.

Par exemple, dans le cas des contrôles d'authentification, les exigences de sécurité suivantes peuvent être documentées du point de vue des menaces et des contre-mesures :

• Crypter les données d'authentification en stockage et en transit pour atténuer le risque de divulgation d'informations et les attaques de protocole d'authentification.
• Crypter les mots de passe en utilisant un cryptage non réversible, tel que l'utilisation d'un condensé (par exemple, HASH) et d'une graine pour empêcher les attaques par dictionnaire.
• Verrouiller les comptes après avoir atteint un seuil d'échec de connexion et appliquer la complexité du mot de passe pour atténuer le risque d'attaques par force brute sur les mots de passe.
• Afficher des messages d'erreur génériques lors de la validation des informations d'identification pour atténuer le risque de collecte ou d'énumération de comptes.
• Authentifier mutuellement le client et le serveur pour empêcher la non-répudiation et les attaques de l'homme du milieu (MiTM).

Les outils de modélisation des menaces tels que les arbres de menaces et les bibliothèques d'attaques peuvent être utiles pour dériver les scénarios de test négatifs. Un arbre de menaces supposera une attaque racine (par exemple, l'attaquant pourrait être capable de lire les messages des autres utilisateurs) et identifiera différents exploits des contrôles de sécurité (par exemple, la validation des données échoue en raison d'une vulnérabilité d'injection SQL) et les contre-mesures nécessaires (par exemple, mettre en oeuvre la validation des données et les requêtes paramétrées) qui pourraient être validées pour être efficaces pour atténuer ces attaques.

Dérivation des exigences de test de sécurité par le biais de cas d'utilisation et de cas d'abus

Une condition préalable à la description de la fonctionnalité de l'application est de comprendre ce que l'application est censée faire et comment. Cela peut être fait en décrivant des cas d'utilisation. Les cas d'utilisation, sous la forme graphique telle qu'elle est couramment utilisée en génie logiciel, montrent les interactions des acteurs et leurs relations. Ils aident à identifier les acteurs de l'application, leurs relations, la séquence d'actions prévue pour chaque scénario, les actions alternatives, les exigences particulières, les préconditions et les post-conditions.

Semblables aux cas d'utilisation, les cas d'utilisation abusive ou d'abus décrivent des scénarios d'utilisation non intentionnels et malveillants de l'application. Ces cas d'utilisation abusive offrent un moyen de décrire des scénarios de la façon dont un attaquant pourrait utiliser à mauvais escient et abuser de l'application. En parcourant les étapes individuelles d'un scénario d'utilisation et en réfléchissant à la façon dont il peut être exploité de manière malveillante, les failles potentielles ou les aspects de l'application qui ne sont pas bien définis peuvent être découverts. La clé est de décrire tous les scénarios d'utilisation et d'utilisation abusive possibles ou, du moins, les plus critiques.

Les scénarios d'utilisation abusive permettent l'analyse de l'application du point de vue de l'attaquant et contribuent à l'identification des vulnérabilités potentielles et des contre-mesures qui doivent être mises en oeuvre pour atténuer l'impact causé par l'exposition potentielle à de telles vulnérabilités. Etant donné tous les cas d'utilisation et d'abus, il est important de les analyser pour déterminer lesquels sont les plus critiques et doivent être documentés dans les exigences de sécurité. L'identification des cas d'utilisation abusive et d'abus les plus critiques conduit à la documentation des exigences de sécurité et des contrôles nécessaires où les risques de sécurité doivent être atténués.

Pour dériver les exigences de sécurité à partir des cas d'utilisation et des cas d'abus, il est important de définir les scénarios fonctionnels et les scénarios négatifs et de les mettre sous forme graphique. L'exemple suivant est une méthodologie étape par étape pour le cas de la dérivation des exigences de sécurité pour l'authentification.

Etape 1 : Décrire le scénario fonctionnel

L'utilisateur s'authentifie en fournissant un nom d'utilisateur et un mot de passe. L'application accorde l'accès aux utilisateurs sur la base de l'authentification des informations d'identification de l'utilisateur par l'application et fournit des erreurs spécifiques à l'utilisateur lorsque la validation échoue.

Etape 2 : Décrire le scénario négatif

L'attaquant brise l'authentification par une attaque par force brute ou par dictionnaire des mots de passe et des vulnérabilités de collecte de comptes dans l'application. Les erreurs de validation fournissent des informations spécifiques à un attaquant qui sont utilisées pour deviner quels comptes sont des comptes enregistrés valides (noms d'utilisateur). L'attaquant tente alors de forcer brutalement le mot de passe d'un compte valide. Une attaque par force brute sur des mots de passe d'une longueur minimale de quatre chiffres peut réussir avec un nombre limité de tentatives (c'est-à-dire 10^4).

Etape 3 : Décrire les scénarios fonctionnels et négatifs avec le cas d'utilisation et le cas d'abus

L'exemple graphique ci-dessous illustre la dérivation des exigences de sécurité via les cas d'utilisation et les cas d'abus. Le scénario fonctionnel comprend les actions de l'utilisateur (saisie d'un nom d'utilisateur et d'un mot de passe) et les actions de l'application (authentification de l'utilisateur et fourniture d'un message d'erreur en cas d'échec de la validation). Le cas d'abus comprend les actions de l'attaquant, c'est-à-dire la tentative de briser l'authentification en forçant brutalement le mot de passe via une attaque par dictionnaire et en devinant les noms d'utilisateur valides à partir des messages d'erreur. En représentant graphiquement les menaces pour les actions de l'utilisateur (abus), il est possible de dériver les contre-mesures comme les actions de l'application qui atténuent ces menaces.

Figure 2-5 : Cas d'utilisation et cas d'abus

Etape 4 : Obtenir les exigences de sécurité

Dans ce cas, les exigences de sécurité suivantes pour l'authentification sont dérivées :

1. Les exigences relatives aux mots de passe doivent être alignées sur les normes actuelles pour une complexité suffisante.
2. Les comptes doivent être verrouillés après cinq tentatives de connexion infructueuses.
3. Les messages d'erreur de connexion doivent être génériques.

Ces exigences de sécurité doivent être documentées et testées.