Vá aos poucos.
Embora isso já tenha sido mencionado antes, vale a pena revisitar. Pode ser tentador lançar seu programa "publicamente", anunciando-o para o mundo e, no caso de um programa interno, tornar sua política do programa e o formulário de envio de relatórios publicamente acessíveis. Isso pode ser arriscado, porque não dá a chance de você começar aos poucos e escalonar verticalmente. Não importa quanto você se prepara, sempre haverá surpresas ao iniciar um VDP. Talvez você receba mais vulnerabilidades do que o esperado e não consiga acompanhá-las. Talvez metade da sua equipe fique doente e não possa ajudar a fazer a triagem de bugs. Talvez você tenha se esquecido de tentar executar verificações autenticadas e, quando um pesquisador fizer isso, ele acidentalmente sobrecarrega seu sistema criando 100.000 contas novas. Não importa quais sejam as surpresas, é melhor começar aos poucos e ir aumentando lentamente seu programa ao longo do tempo. Você terá problemas, o que é totalmente normal, mas é melhor ter a largura de banda para lidar com cada um deles.
Se você decidiu criar seu programa internamente, ainda pode manter a Política do Programa e o formulário de envio de denúncia no seu site, mas talvez seja necessário exigir que os hackers façam login antes de acessar o conteúdo. Se você estiver usando uma plataforma de terceiros, ela convidará automaticamente um pequeno conjunto de pesquisadores de segurança. Em ambos os casos, é possível criar um modelo de convite para convidar hackers ao VDP particular, desta forma:
Olá, <Nome da sua organização> quer convidar você para participar do nosso VDP particular. Começamos aos poucos no modo privado para que possamos usar nossos processos de VDP e proporcionar a melhor experiência possível aos pesquisadores de segurança. Consulte nossa Política do Programa para ver as diretrizes e o escopo de teste. Se você tiver algum feedback nos estágios iniciais do VDP, entre em contato conosco.Depois que seu primeiro conjunto de pesquisadores tiver sido convidado e receber acesso ao seu programa, os relatórios começarão a ser enviados. Ou você pode não receber nenhum relatório, mas não tem problema. Digamos que você convidou cinco pesquisadores de segurança. É possível que dois deles estejam muito ocupados e decidam não analisar seu programa. Outro usuário pode estar de férias e não receber a mensagem do seu convite. O quarto e o quinto hackers podem dar uma olhada e fazer alguns testes por um ou dois dias, mas não encontrar nenhuma vulnerabilidades. Talvez eles voltem algumas semanas depois e informem algo, mas ainda pode ser chocante passar por todo esse trabalho, enviar convites e não receber nenhum relatório. Se isso acontecer, não se preocupe. Isso é totalmente normal, e é por isso que você quer começar aos poucos e escalonar verticalmente. Se você enviar cinco convites e não estiver vendo muito volume de relatórios, envie mais cinco, depois mais cinco, dez ou até mesmo vinte. Se você usa uma plataforma de terceiros, ela tem mecanismos automatizados que convidam hackers lentamente ao longo do tempo com base no volume de relatórios desejado. Por outro lado, se você receber um grande número de relatórios de vulnerabilidade depois de convidar apenas cinco pesquisadores de segurança, talvez convém convidar mais até que o volume de relatórios diminua.
Triagem e iteração
Nas primeiras semanas após o lançamento do VDP, é possível que você tenha duas ou mais pessoas de serviço ao mesmo tempo para ajudar na triagem de relatórios de vulnerabilidade recebidos, no registro de bugs e na comunicação com os pesquisadores. Normalmente, há um grande pico de relatórios no lançamento de um programa, que acaba com o tempo. Ao fazer a triagem dos relatórios de vulnerabilidade recebidos, você pode receber feedback dos hackers e identificar lacunas ou mal-entendidos na política do programa. Também é possível encontrar problemas nos seus processos e ferramentas. À medida que você começa pequeno e recebe muita atenção e energia da equipe nessas primeiras semanas, use esse tempo para iterar e melhorar rapidamente seu programa. Depois de um ou dois meses, as coisas vão parar de funcionar, e executar o programa sem problemas passará a ser algo inesquecível.
Escalonar verticalmente, lançar publicamente
À medida que sua equipe se acostumar a administrar o programa, você convida cada vez mais hackers para participar. Você ampliou seu escopo para incluir tudo o que sabe (e até mesmo recursos que talvez não percebesse que existiam). Em algum momento, é possível que você convide cem ou até centenas de hackers, mas o volume de relatórios parece estar diminuindo. Os relatórios enviados parecem ser de gravidade baixa ou média. A rotação de serviço parece ser relativamente leve, e sua equipe é bem experiente em triagem de relatórios de vulnerabilidade, empurrá-los para a resolução e se comunicar com hackers. Neste ponto, você provavelmente está pronto para lançar seu programa publicamente. Antes de fazer isso, reconecte-se com todas as partes interessadas para garantir que elas estejam cientes e aceitaram o lançamento público. Assim como no lançamento particular inicial, prepare sua equipe para outro possível aumento no volume de relatórios do lançamento público. Uma diferença fundamental ao lançar publicamente é que qualquer pessoa pode enviar um relatório de vulnerabilidade para você. Lembre-se de que isso pode gerar muito ruído. Por exemplo, usuários que estejam confusos sobre como fazer login na conta ou até mesmo bots de spam preenchendo formulários e enviando e-mails automaticamente podem enviar relatórios ao VDP. É importante ter modelos para fechar rapidamente relatórios comuns não relacionados à segurança, ou até mesmo evitar isso ajustando seu formulário para redirecionar os usuários ao lugar certo (por exemplo, sua equipe de suporte para casos como senhas esquecidas). Pelo lado positivo, ao abrir seu programa ao público, hackers habilidosos que não tinham como entrar em contato com você antes agora podem fazer isso. Isso pode ajudar você a descobrir vulnerabilidades de gravidade alta ou crítica que você não sabia que existiam. Ele também inclui todos os benefícios mencionados anteriormente neste guia, incluindo ter um canal padronizado para que a comunidade global de hackers divulgue vulnerabilidades diretamente para você, reduzindo o risco de violações e relações públicas negativas.
Comemore a participação dos fãs
Parabéns! Você percorreu um longo caminho e agora tem um VDP público. Não se esqueça de comemorar com sua equipe e todas as partes interessadas que ajudaram você ao longo do caminho. É importante expressar sua gratidão e encontrar uma maneira de comemorar seu sucesso juntos. Além de comemorar o lançamento público do VDP, não se esqueça de comemorar os marcos ao longo do caminho, como o aniversário de um ano do lançamento público, ou destacando bugs particularmente interessantes e críticos que foram encontrados e corrigidos pelo VDP. Reunir métricas ao longo do caminho pode ajudar a demonstrar o sucesso do programa e destacar as realizações de você e sua equipe.