Le règlement d'un programme est essentiel pour tout VDP et doit être élaboré avec soin. Le règlement du programme est la première chose que les chercheurs en sécurité voient lorsqu'ils participent à un VDP. Il donne le ton au programme, définit les attentes et définit votre engagement envers les chercheurs qui choisissent de participer.
Créer et héberger le règlement du programme
Suivez les consignes ci-dessous pour rédiger le règlement du programme de votre VDP. Le règlement du programme ne comporte généralement qu'une à trois pages et traite des sujets suivants:
- Promesse d'un chercheur
- Consignes de test
- Portée du programme
Le règlement du programme doit être accessible à tous les chercheurs potentiels. Si vous prévoyez de ne proposer le VDP qu'à quelques chercheurs invités, le règlement du programme nécessite une sorte de contrôle d'accès pour le rendre accessible aux chercheurs que vous avez invités, mais limité à tous les autres. Les chercheurs ont également besoin d'un moyen de soumettre des rapports, tels qu'un formulaire Web ou un alias d'adresse e-mail connecté à un système de tickets pour suivre les rapports. Tenez-en compte lorsque vous configurez les ressources en ligne du VDP.
Les plates-formes tierces de divulgation des failles et de prime au bug offrent généralement les fonctionnalités suivantes:
- Façon vous permettant de créer, modifier et publier des règles
- Contrôles d'accès pour créer un programme privé
- Inviter automatiquement des hackers à un rythme confortable
- Fonctionnalité de boîte de réception facilitant le traitement des rapports entrants
Les plates-formes tierces proposent également divers services de conseil pour faciliter le processus de création et de lancement d'un VDP. Généralement, les plates-formes et les services de conseil tiers ont un coût. Tenez compte des coûts et des avantages liés à l'utilisation d'un tiers par rapport à la création et à la gestion de votre programme en interne afin de déterminer la meilleure voie à suivre pour votre organisation.
Pour en savoir plus sur les éléments à inclure dans le règlement de votre programme, consultez l'article A Framework for a Vulnerability Divulgation Program for Online Systems du ministère de la Justice des États-Unis.
Partenaires du règlement du programme
Lorsque vous rédigez le règlement de votre programme, réfléchissez à la manière de travailler avec vos partenaires. Différentes équipes peuvent fournir des commentaires sur les éléments à prendre en compte dans votre stratégie.
| Partenaire | Points à prendre en compte |
|---|---|
| Juridique |
|
| IT |
|
| Ingénierie |
|
| PR |
|
| Sécurité |
|
Promesse auprès des chercheurs
La promesse du chercheur explique les engagements de l'organisation envers les chercheurs participants qui agissent de bonne foi en suivant les directives de test décrites dans le règlement. Par exemple, vous vous engagez à répondre à tous les rapports de sécurité entrants dans un délai spécifique, et à communiquer les décisions concernant les rapports de faille acceptés et corrigés.
Exemple :
<Nom de votre organisation> s'engage à collaborer avec les chercheurs en sécurité pour identifier et corriger les failles de ses systèmes et services. Tant que vous agissez de bonne foi et respectez les consignes décrites dans les présentes règles, nous nous efforcerons de respecter les règles suivantes:- Fournir une première réponse à votre rapport de faille dans un délai de trois jours ouvrés
- Déterminer si nous accepterons (nous l'avons l'intention de corriger) ou si nous rejetons (identifierons votre rapport comme étant un faux positif ou un risque acceptable) votre rapport sur les failles dans un délai de 10 jours ouvrés
- Tenez-vous informé de l'avancée de la correction des signalements que nous acceptons de votre part
L'adoption de la réglementation du programme permet d'indiquer aux chercheurs qu'aucune action en justice ne sera intentée à l'encontre de vos systèmes, à condition qu'ils agissent de bonne foi et respectent toutes les consignes expliquées dans le règlement.
Consignes de test
Les consignes de test décrivent les tests de sécurité couverts par le VDP ainsi que les tests qui n'entrent pas dans le champ d'application et doivent être évités par les chercheurs. Si vous souhaitez que les chercheurs se concentrent sur des types spécifiques de failles, cette section est un bon endroit pour les mettre en évidence.
Exemple:
Lorsque vous effectuez des tests de sécurité, veuillez respecter les consignes suivantes:
- Effectuez des tests uniquement sur vos propres comptes et données (par exemple, créez des comptes de test). Si vous identifiez une faille qui pourrait entraîner l'accès aux données d'autres utilisateurs, veuillez nous contacter avant d'effectuer d'autres tests.
- Si vous accédez par inadvertance aux données d'autres utilisateurs pendant vos tests, veuillez nous en informer et ne stocker aucune de ces données utilisateur.
- N'effectuez pas de tests qui pourraient entraîner des conditions de déni de service ou une dégradation de nos services de production.
- L'ingénierie sociale n'entre pas dans le champ d'application de ce programme. N'essayez pas d'ingénierie sociale de notre organisation ou de nos utilisateurs.
Nous sommes particulièrement intéressés par les types de failles et d'impacts suivants:
- Exécution de code à distance
- XSS entraînant l'accès à des données sensibles (informations de session, par exemple)
- Injection SQL entraînant l'accès à des données ou à des fonctionnalités sensibles
- Défaillances de la logique métier entraînant l'accès à des données ou à des fonctionnalités sensibles
Les types de failles suivants nous intéressent moins, car ils sont plus susceptibles d'
être rejetés en tant que faux positifs ou risques acceptés:
- Manque de l'en-tête X-Frame-Options sur les pages sans fonctionnalité de changement d'état
- Résultats d'analyse automatisés non validés
- Problèmes peu susceptibles d'être exploités et/ou n'ayant pas d'impact réaliste sur la sécurité
Définition du champ d'application
Le champ d'application définit les éléments que les chercheurs peuvent tester, ainsi que ceux qui ne sont pas considérés comme faisant partie du VDP. La portée doit être soigneusement considérée et aussi vaste que possible sans surcharger votre équipe. Plus vous êtes prêt à en intégrer, plus vous aurez de chances d'obtenir l'engagement des chercheurs en sécurité. Cependant, ne limitez pas le champ d'application au point que votre équipe ne puisse pas suivre les rapports entrants. Commencez par quelques ressources dans la portée. Étendez le champ d'application à mesure que vous vous faites une meilleure idée du volume de rapports que vous recevrez. Avant de rendre votre VDP accessible au public au fil du temps, assurez-vous que tous les éléments entrent dans le champ d'application.
Concernant la manière de définir votre champ d'application dans le règlement de votre programme, l'ajout de détails sur chaque élément ou domaine aidera les chercheurs en sécurité à savoir ce qui est important pour vous et sur quoi concentrer leurs efforts. Vous pouvez également inclure des conseils sur la façon de tester vos ressources de manière sécurisée. Exemple :
| Asset | mail.example.com |
|---|---|
| Description | Domaine principal permettant aux utilisateurs d'accéder à leurs e-mails. |
| Failles et impacts intéressants |
|
| Problèmes susceptibles d'être refusés |
|
| Consignes relatives aux tests | Effectuez des tests uniquement avec des comptes dont vous êtes le propriétaire ou pour lesquels vous avez explicitement donné votre autorisation. Lorsque vous créez des comptes de test, veuillez inclure "vdptest" dans le nom d'utilisateur. Vous pouvez créer des comptes de test à l'adresse mail.example.com/new. |
Cette répartition est assez détaillée. Vous pouvez également inclure une simple liste des éléments inclus dans le champ d'application et hors champ d'application:
Dans le champ de compétences
- mail.example.com
- example.com
Non prise en charge
- blog.example.com
Attribuer des ressources à votre VDP
Vous aurez besoin de certaines ressources avant de lancer un VDP. Vous aurez besoin de ressources pour:
- Examiner les rapports de failles entrants
- Communiquer avec les hackers
- Rechercher des propriétaires d'éléments et signaler des bugs
- Corriger les bugs
- Gestion des failles / suivi de la correction
Réexaminer les principaux partenaires
Si vous ne l'avez pas déjà fait, revoyez les conversations avec les principaux partenaires avec lesquels vous avez discuté précédemment de votre VDP afin de vous assurer qu'ils sont alignés sur le calendrier de lancement de votre VDP et de mettre en file d'attente les ressources nécessaires au lancement. Par exemple, vous pouvez collaborer avec la direction de l'ingénierie pour vous assurer que ses équipes sont prêtes à faire face à un afflux potentiel de bugs de sécurité dans les premières semaines suivant le lancement. Au sein de votre équipe de sécurité, assurez-vous que les personnes qui examinent les alertes de vos systèmes de détection et de réponse sont au courant de la date de lancement du VDP, et envisagez d'allouer plus de temps et de ressources au début des tests. Vous devrez également constituer une équipe chargée des opérations quotidiennes de votre VDP.
Constituez votre équipe
L'exécution d'un VDP nécessite une certaine quantité de travail opérationnel et piloté par des interruptions. Si vous essayez d'examiner, de valider techniquement et de répondre à chaque rapport de faille reçu, de classer tous les bugs, d'effectuer le suivi des états et de communiquer vous-même les mises à jour aux chercheurs, vous risquez de vous surmener. Même si vous ne disposez pas d'une grande équipe de sécurité, faites appel à des volontaires soucieux de la sécurité pour vous aider à constituer une équipe qui vous aidera à opérationnaliser et à exécuter votre VDP. Vous voudrez tout de même qu'un "propriétaire" ou un "responsable" défini de votre VDP soit responsable de la réussite de votre VDP, mais vous aurez également besoin d'une équipe pour soutenir ce responsable.
Établir un planning de service
Une fois que vous avez des ressources en place et que vous êtes prêt à vous aider avec votre VDP, créez une structure derrière le projet en mettant en place un calendrier de service. Vous pouvez créer cela comme vous le souhaitez, mais une rotation hebdomadaire est assez courante. Lorsque vous êtes en service pour la semaine, il vous incombe de:
- Tri : examinez les rapports de failles entrants.
- Valider techniquement le rapport et prendre la décision d'accepter ou de refuser
- Communiquer votre décision au hacker qui a signalé le problème
- Si nécessaire, demandez plus d'informations au hacker si vous ne parvenez pas à reproduire le problème.
- Si la faille est valide, signalez un bug corrigé avec le propriétaire approprié.
- Gestion des failles : repoussez les failles existantes.
- Examinez les bugs signalés au cours des dernières semaines de service pour vous assurer que les corrections sont en cours en fonction de vos normes de gravité et de vos délais de résolution.
- Utilisez les conseils de la recherche de propriétaires pour les persuader de corriger ces bugs.
- Communiquer : informer les chercheurs en sécurité sur les rapports existants
- Les chercheurs peuvent demander des mises à jour sur les rapports existants de manière proactive. Vérifiez si c'est le cas et répondez-y si nécessaire.
- Si une faille est corrigée, informez-en le chercheur afin qu'il sache que son travail a abouti à un changement positif dans votre organisation. Vous pouvez même inclure un modèle de modèle qui demande au chercheur de vous indiquer si vous avez manqué quelque chose dans votre correction ou si celle-ci peut être contournée d'une manière ou d'une autre.
En fonction du nombre de signalements que vous recevez, de la complexité de ces rapports, et des compétences et connaissances de la personne de service, le fait de travailler en équipe peut prendre de quelques heures à toute la semaine. Voici quelques conseils pour réussir une rotation en service:
- Assurez-vous que votre équipe est prête à intervenir et à soutenir les équipes de service les semaines particulièrement lourdes.
- Mettez en place un bon processus de transfert. Si des problèmes peuvent nécessiter une attention immédiate de la part du prochain collaborateur de service, rédigez des notes de transfert ou discutez en direct à la fin de la semaine.
- Créez un planning automatisé pour que tout le monde sache quand il est de service. Il suffit de créer des entrées d'agenda récurrentes pour chaque individu.
- Au début du VDP en particulier, vérifiez auprès de la personne de service qu'elle se souvient que c'est sa semaine et qu'elle a besoin d'aide. Si vous avez des ressources moins expérimentées dans la rotation, faites en sorte que des collaborateurs plus expérimentés travaillent avec eux pour vous assurer qu'ils se sentent à l'aise et peuvent poser des questions à mesure qu'ils montent en puissance.
- Disposer d'un processus flexible pour l'échange de semaines. Une personne sera inévitablement confrontée à une situation d'urgence et devra prendre des congés pendant sa semaine, ou quelqu'un prendra des vacances, etc. Lorsque cela se produit, encouragez l'équipe à échanger des semaines si nécessaire pour s'adapter aux emplois du temps de chacun.
- Créez un "aide-mémoire" décrivant les tâches à accomplir, y compris la documentation sur la façon de procéder.
Déterminez le type d'intégration (interne ou tiers)
Jusqu'ici, la plupart des conseils fournis concernaient la création et l'exécution de votre VDP en interne. Divers services et plates-formes de conseil peuvent vous aider à créer et à exécuter un VDP. Ces services tiers sont généralement payants, mais ils peuvent vous être utiles pour vous guider dans la création, le lancement et l'exécution de votre VDP. Certains proposent même des services de tri pour vous aider à examiner les rapports de faille entrants, à gérer la communication avec les pirates informatiques et à ne faire remonter que les signalements valides à votre équipe. Le choix entre créer ce processus en interne ou utiliser une plate-forme tierce dépend de vos exigences et des ressources disponibles. Si vous disposez d'un budget important, mais peu d'employés, il peut être judicieux de faire appel à un tiers pour vous aider à gérer votre programme. Si c'est l'inverse, cela peut valoir la peine d'investir le temps nécessaire pour créer votre programme vous-même.
Recevoir des rapports
Si vous décidez d'utiliser une plate-forme tierce, celle-ci doit permettre aux pirates informatiques de vous envoyer directement les signalements. Si vous créez votre programme en interne, vous devrez le créer vous-même. Il peut s'agir d'une adresse e-mail qui crée automatiquement un ticket ou d'un bug dans votre outil de suivi des problèmes (par exemple, security@example.com), ou d'un formulaire Web avec des champs obligatoires, accessibles via un lien ou sur la même page que le règlement de votre programme. Quelle que soit la forme choisie, c'est votre meilleure chance d'informer les hackers du format dans lequel vous souhaitez recevoir vos rapports. Gardez à l'esprit que demander aux pirates informatiques d'envoyer des signalements dans un certain format ne garantit pas qu'ils le feront, mais cela ne fait pas de mal de le demander. Voici un exemple de ce que vous pouvez demander dans un formulaire d'envoi de rapport:
Titre: [Veuillez ajouter une description du problème sur une ligne, par exemple "XSS dans mail.example.com
entraîne le vol de la session"]
1.
2.
3.
Scénario d'attaque et impact: [Comment cela pourrait-il être exploité ? Quel est l'impact sur la sécurité de ce
problème ?]
Conseils de correction: [Facultatif, si vous avez des conseils sur la façon dont ce problème pourrait être résolu, ajoutez-les ici.]