Un test d'intrusion répond à la question écrite dans son périmètre, et à rien d'autre. Si le périmètre dit « tester notre application web », vous obtiendrez un rapport sur ce que les testeurs ont trouvé le plus intéressant dans le temps imparti, ce qui n'est pas forcément ce que vous aviez besoin de savoir.
La solution tient en un mot : la préparation. Définissez la question, les règles, les accès, le traitement des données et la définition de « terminé » avant de demander des devis.
Partir de la question, pas de la cible
Une liste d'adresses IP et d'URL est une liste de cibles, pas un objectif. L'objectif est la décision que le test doit éclairer. Le NIST SP 800-115 indique que les tests techniques de sécurité servent plusieurs finalités, par exemple trouver des vulnérabilités dans un système ou un réseau et vérifier la conformité à une politique ou à d'autres exigences. Ce sont des missions différentes, et elles demandent des tests différents.
Formulez l'objectif en une phrase qu'un sponsor non technique peut lire. Quelques exemples :
- Un client connecté peut-il lire les factures d'un autre client dans le nouveau portail ?
- Un attaquant sans compte peut-il atteindre l'interface d'administration du système de réservation ?
- L'application respecte-t-elle les exigences de contrôle d'accès citées dans le questionnaire de sécurité de notre client ?
Chacune de ces questions implique un périmètre, des comptes et un rapport différents. Si vous ne parvenez pas à écrire cette phrase, vous n'êtes pas encore prêt à acheter. Un court échange de cadrage avec les testeurs ou avec un conseiller, comme notre équipe de conseil, vaut la peine avant de demander des devis.
Choisir un référentiel pour définir « testé »
« Entièrement testé » ne veut rien dire tant que vous n'avez pas nommé le référentiel par rapport auquel le test a été mené. Pour les applications web, deux projets OWASP fournissent un vocabulaire commun.
L'OWASP Application Security Verification Standard (ASVS) sert de base pour tester les mesures de sécurité techniques des applications web, et il donne aux développeurs une liste d'exigences pour un développement sécurisé. La page du projet indique la version 5.0.0 comme dernière version stable. Chaque exigence porte un identifiant numéroté, et le projet recommande de le citer avec la version, par exemple v5.0.0-1.2.5. La version compte, car les identifiants peuvent changer d'une release à l'autre.
L'OWASP Web Security Testing Guide décrit comment tester. Sa page indique la v4.2 comme version courante, la 5.0 étant encore en développement. Inscrivez au contrat la version attendue, faute de quoi chaque partie en supposera une différente.
Précisez ensuite quelles parties de l'ASVS entrent dans le périmètre, par chapitre et par section tels qu'ils figurent dans la version choisie. L'identifiant v5.0.0-1.2.5, par exemple, désigne la 5e exigence de la section « Injection Prevention » du chapitre « Encoding and Sanitization ». Choisissez les sections qui correspondent à votre objectif et demandez que les constats soient rattachés aux identifiants d'exigences. Cela simplifie nettement les contre-tests et le suivi par les développeurs.
Règles d'engagement
Les règles d'engagement sont les limites écrites de ce que les testeurs ont le droit de faire. Il s'agit de nos recommandations et non de prescriptions issues des sources, mais tout document de cadrage devrait trancher les points suivants :
| Point | À décider |
|---|---|
| Environnement | Production, préproduction, ou les deux. La préproduction est plus sûre, mais elle n'est utile que si sa configuration correspond à celle de la production. |
| Fenêtre | Dates et horaires, et si les tests peuvent avoir lieu en dehors des heures ouvrées. |
| Adresses sources | Les IP que les testeurs utiliseront, pour que votre équipe de supervision puisse les distinguer d'un véritable attaquant. |
| Techniques exclues | Le déni de service, l'ingénierie sociale et l'accès physique sont des exclusions courantes. Écrivez-les noir sur blanc dans tous les cas. |
| Conditions d'arrêt | Ce qui doit faire suspendre les tests : une indisponibilité, l'accès à des données personnelles inattendues, un constat critique. |
| Contacts | Deux personnes nommées de chaque côté, avec des numéros de téléphone joignables la nuit. |
Décidez à l'avance si votre SOC sera informé du test. Le prévenir teste le processus, ne pas le prévenir teste la détection. Les deux approches sont valables, mais il faut choisir en connaissance de cause.
Comptes de test et traitement des données
Fournissez des comptes, car un testeur sans identifiants ne peut pas examiner ce qui se trouve derrière l'authentification. Prévoyez un compte par rôle présent dans l'application, plus deux comptes ayant le même rôle mais appartenant à des clients ou des tenants différents. Sans cette paire, impossible de vérifier si un utilisateur peut accéder aux données d'un autre.
Créez les comptes à l'avance, vérifiez qu'ils permettent de se connecter, et indiquez comment l'authentification multifacteur sera gérée.
Convenez du traitement des données dans le contrat :
- Utilisez des données synthétiques en préproduction dès que possible. Si la production est dans le périmètre, précisez quels enregistrements réels les testeurs peuvent consulter et lesquels leur sont interdits.
- Indiquez où seront stockées les preuves (captures d'écran, journaux de requêtes, données extraites), qui peut y accéder et combien de temps les testeurs les conservent.
- Exigez que le rapport lui-même soit transmis chiffré. C'est la liste de vos faiblesses.
- Fixez la règle pour les découvertes sensibles : si les testeurs tombent sur des données personnelles, ils s'arrêtent, notent l'emplacement sans copier le contenu et appellent votre contact.
Critères de réussite et rapport
« Aucun constat critique » n'est pas un critère de réussite. Il récompense un test superficiel. Définissez « terminé » comme la couverture plus la qualité des livrables : les exigences convenues ont été examinées, et chaque constat est accompagné de suffisamment de détails pour être reproduit et corrigé.
Le NIST présente son guide comme une aide à l'analyse des constats et à l'élaboration de stratégies de remédiation, en plus de la conduite des tests. Demandez la même chose. Chaque constat doit comporter les étapes de reproduction, le composant affecté, une cotation de sévérité avec une méthode explicite pour que vous puissiez la vérifier vous-même, et une remédiation concrète. Ajoutez au devis un contre-test des constats corrigés, et convenez de qui valide le rapport et quand.
Si vous achetez auprès d'un prestataire comme notre service de tests d'intrusion, reportez ces points dans le cahier des charges, et pas seulement dans la réunion de lancement.
Par où commencer
- Écrivez l'objectif en une phrase et faites-le valider par le responsable métier.
- Listez les applications, environnements et rôles dans le périmètre, et nommez ce qui est explicitement hors périmètre.
- Choisissez le référentiel : les chapitres et sections de l'ASVS concernés et une version du Web Security Testing Guide, le tout avec les numéros de version.
- Remplissez le tableau des règles d'engagement, y compris les contacts, la fenêtre et les adresses sources.
- Créez et vérifiez les comptes de test, dont deux comptes de même rôle pour des tenants différents, et fixez les règles de traitement des données.
- Inscrivez les critères de réussite au contrat : format des constats, méthode de cotation de la sévérité, rattachement aux identifiants d'exigences et contre-test.
