Procéder par étapes
Bien que cela ait déjà été mentionné, cela vaut la peine d’être revisité. Il peut être tentant de lancer votre programme "publiquement" en l'annonçant au monde entier et, dans le cas d'un programme interne, de rendre le règlement du programme et le formulaire de soumission de rapport accessibles au public. Cela peut être risqué, car cela ne vous donne pas l'occasion de commencer petit et d'effectuer un scaling à la hausse. Peu importe votre niveau de préparation, il y aura toujours des surprises lorsque vous lancerez un VDP. Il se peut que vous receviez plus de failles que prévu et que vous ne puissiez pas suivre le rythme. Peut-être que la moitié de votre équipe tombe malade et ne pourra pas aider à trier les bogues. Vous avez peut-être oublié d'effectuer des analyses authentifiées et, lorsqu'un chercheur le fait, il inonde accidentellement votre système en créant 100 000 nouveaux comptes. Quelles que soient les surprises, il est préférable de commencer petit et de faire évoluer progressivement votre programme au fil du temps. Vous rencontrerez des problèmes, ce qui est tout à fait normal. Toutefois, il est préférable de disposer de la bande passante nécessaire pour les gérer un par un.
Si vous avez décidé de créer votre programme en interne, vous devrez toujours afficher le règlement du programme et le formulaire d'envoi de rapport sur votre site Web, mais vous devrez peut-être obliger les pirates informatiques à se connecter avant de pouvoir les consulter. Si vous utilisez une plate-forme tierce, celle-ci se chargera automatiquement d'inviter un petit groupe de chercheurs en sécurité pour vous. Dans les deux cas, vous pouvez créer un modèle d'invitation pour inviter des pirates informatiques à rejoindre votre VDP privé, comme ceci:
Bonjour, <Nom de votre organisation> souhaite vous inviter à participer à notre VDP privé. Nous commençons à présent à petite échelle en mode privé pour pouvoir nous appuyer sur nos processus VDP et offrir la meilleure expérience possible aux chercheurs en sécurité. Veuillez consulter le règlement du programme pour connaître les consignes de test et le champ d'application. N'hésitez pas à nous faire part de vos commentaires dès les premières étapes de notre VDP.Une fois que votre premier groupe de chercheurs a été invité et autorisé à accéder à votre programme, les rapports commencent à arriver. Vous ne recevrez peut-être aucun rapport, mais ce n'est pas grave. Imaginons que vous invitiez cinq chercheurs en sécurité. Il est possible que deux d'entre eux soient trop occupés et décident de ne pas du tout examiner votre programme. Un autre est peut-être en vacances et a manqué votre message d'invitation. Les quatrième et cinquième pirates informatiques peuvent jeter un œil et effectuer des tests pendant un jour ou deux, mais sans trouver de failles. Il pourrait y revenir quelques semaines plus tard et signaler quelque chose, mais il peut toujours être choquant d'effectuer tout ce travail, d'envoyer des invitations et de ne recevoir aucun rapport. Ne vous inquiétez pas si cela se produit. C'est tout à fait normal, et c'est pourquoi vous devez commencer petit et vous développer. Si vous envoyez cinq invitations et que le volume de rapports n'est pas élevé, envoyez-en cinq de plus, puis cinq, dix, voire vingt. Si vous utilisez une plate-forme tierce, sachez qu'elle dispose de mécanismes automatisés qui invitent les pirates informatiques au fil du temps en fonction du volume de rapports souhaité. À l'inverse, si vous recevez un grand nombre de rapports de failles après n'avoir invité que cinq chercheurs en sécurité, vous pouvez choisir d'en envoyer davantage jusqu'à ce que le volume de rapports ralentisse.
Triez et itérez
Au cours des deux premières semaines suivant le lancement de votre programme de divulgation des failles, il peut être utile d'avoir simultanément deux personnes de garde ou plus afin de trier les rapports de failles entrants, de signaler les bugs et de communiquer avec les chercheurs. Il y a généralement un pic de rapports élevé au lancement d'un programme, puis il s'atténue au fil du temps. Lorsque vous triez les rapports de faille entrants, vous pouvez recevoir des commentaires de hackers et identifier des lacunes ou des malentendus dans le règlement de votre programme. Vous pourriez également trouver des problèmes dans vos processus et vos outils. Vous commencez petit et avez beaucoup d'attention et d'énergie de la part de votre équipe au cours des deux premières semaines. Profitez de ce temps pour itérer et améliorer rapidement votre programme. Au bout d'un ou deux mois, les choses s'arrangeront et le bon déroulement de votre programme deviendra une seconde nature.
Scaling à la hausse, lancement public
Au fur et à mesure que votre équipe s'habituera à gérer votre programme, vous inviterez de plus en plus de pirates informatiques à y participer. Vous avez élargi votre champ d'application pour inclure tout ce que vous savez (et même les éléments dont vous n'aviez peut-être pas réalisé l'existence). Il est possible que vous arriviez à un point où vous avez invité une centaine, voire quelques centaines de pirates informatiques, mais le volume de rapports semble diminuer. Les rapports envoyés semblent tous avoir un niveau de gravité faible ou moyen. La rotation des tâches semble relativement simple, et votre équipe sait parfaitement comment trier les rapports de failles, comment les résoudre et comment communiquer avec les pirates informatiques. À ce stade, vous êtes probablement prêt à lancer votre programme publiquement. Avant de le faire, renouez avec tous vos partenaires pour vous assurer qu’ils sont au courant et ont accepté votre lancement public. Comme pour votre lancement privé initial, préparez votre équipe à une autre augmentation potentielle du volume des rapports pour votre lancement public. L'une des principales différences lors d'un lancement public est que tout le monde peut vous envoyer un rapport de faille. Gardez à l'esprit que cela peut générer beaucoup de bruit. Par exemple, les utilisateurs qui ne savent pas comment se connecter à leur compte, ou même les robots spammeurs qui remplissent des formulaires et envoient automatiquement des e-mails peuvent envoyer des rapports à votre VDP. Il est utile de mettre en place des modèles pour fermer rapidement les rapports courants non liés à la sécurité, ou même éviter cela en ajustant votre formulaire afin de rediriger les utilisateurs vers le bon endroit (par exemple, votre personnel d'assistance pour des choses comme les mots de passe oubliés). En revanche, en ouvrant votre programme au public, les pirates chevronnés qui n'avaient aucun moyen de vous contacter auparavant seront désormais en mesure de le faire. Cela peut vous aider à détecter des failles de gravité élevée ou critique dont vous ignoriez l'existence. Cela s'accompagne également de tous les avantages mentionnés précédemment dans ce guide, comme la possibilité de disposer d'un canal standardisé permettant à la communauté mondiale de hackers de vous divulguer directement les failles, ce qui réduit le risque de violation et de relations publiques négatives.
Célébrez
Félicitations, vous avez parcouru un long chemin ! Vous disposez désormais d'un VDP public. N'oubliez pas de célébrer avec votre équipe et tous les partenaires qui vous ont aidé tout au long du projet. Il est important d'exprimer votre gratitude et de trouver un moyen de célébrer votre réussite ensemble. En plus de célébrer le lancement public de votre VDP, n'oubliez pas de célébrer les étapes importantes du processus, comme l'anniversaire de votre lancement public, ou en mettant en avant les bugs particulièrement intéressants et critiques qui ont été détectés et corrigés via votre VDP. La collecte d'indicateurs tout au long du processus peut contribuer à démontrer le succès de votre programme et mettre en évidence vos réalisations et celles de votre équipe.