Principes des tests

Introduction

Il existe certaines idées fausses courantes lors de l'élaboration d'une méthodologie de test pour trouver des bogues de sécurité dans les logiciels. Ce chapitre couvre certains des principes de base que les professionnels doivent prendre en compte lors de l'exécution de tests de sécurité sur les logiciels.

Il n'y a pas de solution miracle

Bien qu'il soit tentant de penser qu'un scanner de sécurité ou un pare-feu applicatif fournira de nombreuses défenses contre les attaques ou identifiera une multitude de problèmes, en réalité, il n'y a pas de solution miracle au problème des logiciels non sécurisés. Les logiciels d'évaluation de la sécurité des applications, bien qu'utiles comme première passe pour trouver les fruits à portée de main, sont généralement immatures et inefficaces pour une évaluation approfondie ou pour fournir une couverture de test adéquate. N'oubliez pas que la sécurité est un processus et non un produit.

Pensez stratégiquement, pas tactiquement

Les professionnels de la sécurité ont pris conscience de l'erreur du modèle « patch-and-penetrate » qui était omniprésent dans la sécurité de l'information dans les années 1990. Le modèle « patch-and-penetrate » consiste à corriger un bogue signalé, mais sans investigation appropriée de la cause profonde. Ce modèle est généralement associé à la fenêtre de vulnérabilité, également appelée fenêtre d'exposition, illustrée dans la figure ci-dessous. L'évolution des vulnérabilités des logiciels courants utilisés dans le monde entier a montré l'inefficacité de ce modèle. Pour plus d'informations sur les fenêtres d'exposition, voir Schneier on Security.

Des études de vulnérabilité telles que le Rapport sur les menaces de sécurité de Symantec ont montré qu'avec le temps de réaction des attaquants dans le monde entier, la fenêtre de vulnérabilité typique ne laisse pas suffisamment de temps pour l'installation des correctifs, car le temps entre la découverte d'une vulnérabilité et le développement et la publication d'une attaque automatisée contre celle-ci diminue chaque année.

Il existe plusieurs hypothèses incorrectes dans le modèle « patch-and-penetrate ». De nombreux utilisateurs pensent que les correctifs interfèrent avec les opérations normales ou pourraient casser les applications existantes. Il est également incorrect de supposer que tous les utilisateurs sont au courant des correctifs récemment publiés. Par conséquent, tous les utilisateurs d'un produit n'appliqueront pas les correctifs, soit parce qu'ils pensent que l'application de correctifs peut interférer avec le fonctionnement du logiciel, soit parce qu'ils ne connaissent pas l'existence du correctif.

Figure 2-2 : Fenêtre de vulnérabilité

Il est essentiel d'intégrer la sécurité dans le cycle de vie du développement logiciel (SDLC) pour prévenir les problèmes de sécurité récurrents au sein d'une application. Les développeurs peuvent intégrer la sécurité dans le SDLC en élaborant des normes, des politiques et des directives qui s'intègrent et fonctionnent dans la méthodologie de développement. La modélisation des menaces et d'autres techniques doivent être utilisées pour aider à affecter les ressources appropriées aux parties d'un système qui sont les plus à risque.

Le SDLC est roi

Le SDLC est un processus bien connu des développeurs. En intégrant la sécurité dans chaque phase du SDLC, il permet une approche holistique de la sécurité des applications qui tire parti des procédures déjà en place au sein de l'organisation. Sachez que si les noms des différentes phases peuvent changer en fonction du modèle SDLC utilisé par une organisation, chaque phase conceptuelle du SDLC archétype sera utilisée pour développer l'application (c'est-à-dire, définir, concevoir, développer, déployer, maintenir). Chaque phase a des considérations de sécurité qui devraient faire partie du processus existant, afin d'assurer un programme de sécurité rentable et complet.

Il existe plusieurs cadres SDLC sécurisés qui fournissent des conseils à la fois descriptifs et prescriptifs. Le fait qu'une personne suive des conseils descriptifs ou prescriptifs dépend de la maturité du processus SDLC. Essentiellement, les conseils prescriptifs montrent comment le SDLC sécurisé devrait fonctionner, et les conseils descriptifs montrent comment il est utilisé dans le monde réel. Les deux ont leur place. Par exemple, si vous ne savez pas par où commencer, un cadre prescriptif peut fournir un menu de contrôles de sécurité potentiels qui peuvent être appliqués dans le SDLC. Des conseils descriptifs peuvent ensuite aider à orienter le processus de décision en présentant ce qui a bien fonctionné pour d'autres organisations. Les SDLC sécurisés descriptifs incluent BSIMM ; et les SDLC sécurisés prescriptifs incluent le Open Software Assurance Maturity Model (OpenSAMM) d'OWASP, et ISO/IEC 27034 Parties 1 à 7, toutes publiées (sauf la partie 4).

Tester tôt et tester souvent

Lorsqu'un bogue est détecté tôt dans le SDLC, il peut être corrigé plus rapidement et à moindre coût. Un bogue de sécurité n'est pas différent d'un bogue fonctionnel ou de performance à cet égard. Une étape clé pour rendre cela possible est d'éduquer les équipes de développement et d'assurance qualité sur les problèmes de sécurité courants et les moyens de les détecter et de les prévenir. Bien que de nouvelles bibliothèques, de nouveaux outils ou de nouveaux langages puissent aider à concevoir des programmes avec moins de bogues de sécurité, de nouvelles menaces apparaissent constamment et les développeurs doivent être conscients des menaces qui affectent les logiciels qu'ils développent. L'éducation aux tests de sécurité aide également les développeurs à acquérir l'état d'esprit approprié pour tester une application du point de vue d'un attaquant. Cela permet à chaque organisation de considérer les problèmes de sécurité comme faisant partie de ses responsabilités existantes.

Automatisation des tests

Dans les méthodologies de développement modernes telles que (mais sans s'y limiter) : agile, devops/devsecops, ou le développement rapide d'applications (RAD), il convient d'envisager d'intégrer les tests de sécurité dans les flux de travail d'intégration continue/déploiement continu (CI/CD) afin de maintenir les informations/analyses de sécurité de base et d'identifier les faiblesses de type « fruits à portée de main ». Cela peut être fait en tirant parti des tests de sécurité des applications dynamiques (DAST), des tests de sécurité des applications statiques (SAST) et de l'analyse de la composition des logiciels (SCA) ou des outils de suivi des dépendances pendant les flux de travail de publication automatisés standard ou sur une base régulière.

Comprendre la portée de la sécurité

Il est important de savoir quelle quantité de sécurité un projet donné nécessitera. Les actifs à protéger doivent recevoir une classification qui indique comment ils doivent être traités (par exemple, confidentiel, secret, très secret). Des discussions devraient avoir lieu avec un conseiller juridique pour s'assurer que toutes les exigences de sécurité spécifiques seront respectées. Aux Etats-Unis, les exigences peuvent provenir de réglementations fédérales, telles que la Gramm-Leach-Bliley Act, ou de lois d'Etat, telles que la California SB-1386. Pour les organisations basées dans les pays de l'UE, des réglementations nationales spécifiques et des directives européennes peuvent s'appliquer. Par exemple, la Directive 96/46/CE4 et le Règlement (UE) 2016/679 (Règlement général sur la protection des données) rendent obligatoire le traitement des données personnelles dans les applications avec la diligence requise, quelle que soit l'application. Les organisations non européennes, dans certaines circonstances, peuvent également être tenues de se conformer au Règlement général sur la protection des données.

Développer le bon état d'esprit

Pour réussir à tester une application à la recherche de vulnérabilités de sécurité, il faut penser « en dehors de la boîte ». Les cas d'utilisation normaux testeront le comportement normal de l'application lorsqu'un utilisateur l'utilise de la manière attendue. De bons tests de sécurité nécessitent d'aller au-delà de ce qui est attendu et de penser comme un attaquant qui essaie de casser l'application. La pensée créative peut aider à déterminer quelles données inattendues peuvent entraîner l'échec d'une application de manière non sécurisée. Elle peut également aider à trouver les hypothèses faites par les développeurs web qui ne sont pas toujours vraies, et comment ces hypothèses peuvent être renversées. L'une des raisons pour lesquelles les outils automatisés font un mauvais travail de test des vulnérabilités est que les outils automatisés ne pensent pas de manière créative. La pensée créative doit être effectuée au cas par cas, car la plupart des applications web sont développées d'une manière unique (même en utilisant des cadres communs).

Comprendre le sujet

L'une des premières initiatives majeures dans tout bon programme de sécurité devrait être d'exiger une documentation précise de l'application. L'architecture, les diagrammes de flux de données, les cas d'utilisation, etc. doivent être enregistrés dans des documents formels et mis à disposition pour examen. La spécification technique et les documents d'application doivent inclure des informations qui énumèrent non seulement les cas d'utilisation souhaités, mais également tous les cas d'utilisation spécifiquement interdits. Enfin, il est bon d'avoir au moins une infrastructure de sécurité de base qui permette la surveillance et la tendance des attaques contre les applications et le réseau d'une organisation (par exemple, les systèmes de détection d'intrusion).

Utiliser les bons outils

Bien que nous ayons déjà déclaré qu'il n'existe pas d'outil miracle, les outils jouent un rôle essentiel dans le programme de sécurité global. Il existe une gamme d'outils Open Source et commerciaux qui peuvent automatiser de nombreuses tâches de sécurité de routine. Ces outils peuvent simplifier et accélérer le processus de sécurité en aidant le personnel de sécurité dans ses tâches. Cependant, il est important de comprendre exactement ce que ces outils peuvent et ne peuvent pas faire afin qu'ils ne soient pas survendus ou utilisés de manière incorrecte.

Le diable est dans les détails

Il est essentiel de ne pas effectuer une revue de sécurité superficielle d'une application et de la considérer comme complète. Cela instillera un faux sentiment de confiance qui peut être aussi dangereux que de ne pas avoir fait de revue de sécurité en premier lieu. Il est essentiel d'examiner attentivement les résultats et d'éliminer les faux positifs qui pourraient rester dans le rapport. Le signalement d'une conclusion de sécurité incorrecte peut souvent saper le message valide du reste d'un rapport de sécurité. Il faut veiller à vérifier que toutes les sections possibles de la logique de l'application ont été testées et que tous les scénarios de cas d'utilisation ont été explorés pour les vulnérabilités possibles.

Utiliser le code source lorsqu'il est disponible

Bien que les résultats des tests de pénétration en boîte noire puissent être impressionnants et utiles pour démontrer comment les vulnérabilités sont exposées dans un environnement de production, ils ne constituent pas le moyen le plus efficace ou le plus efficient de sécuriser une application. Il est difficile pour les tests dynamiques de tester l'ensemble de la base de code, en particulier s'il existe de nombreuses instructions conditionnelles imbriquées. Si le code source de l'application est disponible, il doit être fourni au personnel de sécurité pour l'aider lors de son examen. Il est possible de découvrir des vulnérabilités dans la source de l'application qui seraient manquées lors d'un engagement en boîte noire.

Désactiver les contrôles de compensation pour les testeurs

Le trafic de test doit être autorisé à traverser les contrôles de compensation tels qu'un pare-feu d'application Web (WAF). Bien qu'un WAF puisse bloquer de nombreuses attaques sur une application, un attaquant sophistiqué peut contourner le contrôle et exploiter l'application sous-jacente vulnérable avec suffisamment de temps et de dévouement. Tout comme fournir un accès au code source, la désactivation du contrôle de compensation permet au personnel de sécurité de consacrer toute son attention à la logique de l'application. Un test de pénétration en boîte blanche vise à trouver des vulnérabilités de sécurité dans le produit lui-même, et non dans les systèmes qui acheminent le trafic vers l'environnement de production.

Développer des métriques

Une partie importante d'un bon programme de sécurité est la capacité de déterminer si les choses s'améliorent. Il est important de suivre les résultats des engagements de test et de développer des mesures qui révéleront les tendances en matière de sécurité des applications au sein de l'organisation.

De bonnes mesures montreront :

• Si plus d'éducation et de formation sont nécessaires ;
• S'il existe un mécanisme de sécurité particulier qui n'est pas clairement compris par l'équipe de développement ;
• Si le nombre total de problèmes liés à la sécurité détectés diminue.

Des mesures cohérentes qui peuvent être générées de manière automatisée à partir du code source disponible aideront également l'organisation à évaluer l'efficacité des mécanismes introduits pour réduire les bogues de sécurité dans le développement de logiciels. Les mesures ne sont pas faciles à développer, donc l'utilisation d'une norme telle que celle fournie par l'IEEE est un bon point de départ.

Documenter les résultats des tests

Pour conclure le processus de test, il est important de produire un enregistrement formel des actions de test qui ont été entreprises, par qui, quand elles ont été effectuées, et les détails des conclusions des tests. Il est sage de convenir d'un format acceptable pour le rapport qui soit utile à toutes les parties concernées, qui peuvent inclure les développeurs, la gestion de projet, les propriétaires d'entreprise, le service informatique, l'audit et la conformité.

Le rapport doit identifier clairement au propriétaire de l'entreprise où des risques importants existent, et le faire d'une manière suffisante pour obtenir leur soutien pour les actions d'atténuation ultérieures. Le rapport doit également être clair pour le développeur en identifiant la fonction exacte qui est affectée par la vulnérabilité et les recommandations associées pour résoudre les problèmes dans un langage que le développeur comprendra. Le rapport doit également permettre à un autre testeur de sécurité de reproduire les résultats. La rédaction du rapport ne doit pas être trop lourde pour le testeur de sécurité lui-même. Les testeurs de sécurité ne sont généralement pas réputés pour leurs compétences en rédaction créative, et l'accord sur un rapport complexe peut conduire à des cas où les résultats des tests ne sont pas correctement documentés. L'utilisation d'un modèle de rapport de test de sécurité peut faire gagner du temps et garantir que les résultats sont documentés avec précision et cohérence, et sont dans un format adapté au public.