Uma política do programa é essencial para qualquer VDP e precisa ser elaborada com cuidado. A política do programa é a primeira coisa que os pesquisadores de segurança veem ao participar de um VDP. Ela define o tom do programa, define expectativas e seu compromisso com os pesquisadores que optam por participar.
Como criar e hospedar a Política do Programa
Use as diretrizes abaixo para redigir a Política do Programa para seu VDP. As políticas do programa geralmente têm de uma a três páginas e incluem os seguintes tópicos:
- Uma promessa do pesquisador
- Diretrizes de teste
- O escopo do programa
A política do programa precisa estar disponível para todos os pesquisadores em potencial. Se você planeja lançar o VDP de forma particular para apenas alguns pesquisadores convidados, a política do programa precisará de algum tipo de controle de acesso para disponibilizá-lo aos pesquisadores convidados, mas restrita a todos os outros. Os pesquisadores também precisam de uma maneira de enviar relatórios, como um formulário da Web ou alias de e-mail conectado a um sistema de tíquetes para rastrear os relatórios. Considere isso ao configurar os recursos on-line do VDP.
As plataformas de divulgação de vulnerabilidades e recompensas de bugs geralmente oferecem recursos como estes:
- Uma maneira de criar, editar e publicar uma política
- Controles de acesso para criar um programa privado
- Convidar hackers automaticamente em um ritmo confortável
- Funcionalidade da caixa de entrada para facilitar o processamento dos relatórios recebidos.
As plataformas de terceiros também oferecem uma variedade de serviços de consultoria para ajudar a facilitar o processo de criação e lançamento de um VDP. Normalmente, plataformas de terceiros e serviços de consultoria têm um custo. Considere os custos e benefícios de usar um terceiro em vez de criar e gerenciar seu programa internamente para determinar o melhor caminho para sua organização.
Para mais inspiração sobre o que incluir na política do programa, leia "A Framework for a Vulnerability nomes Program for Online Systems" (Estrutura para um Programa de divulgação de vulnerabilidade para sistemas on-line) do Departamento de Justiça dos Estados Unidos.
Partes interessadas na política do programa
Ao redigir a Política do Programa, pense em como trabalhar com as partes interessadas. Várias equipes podem fornecer informações sobre considerações para incorporar à sua política.
| Parte interessada | considerações |
|---|---|
| Jurídico |
|
| TI |
|
| Engenharia |
|
| PR |
|
| Segurança |
|
Promessa do pesquisador
A promessa do pesquisador explica os compromissos da organização com os pesquisadores participantes que agem de boa-fé seguindo as diretrizes de teste descritas na política. Por exemplo, um compromisso de responder a todos os relatórios de segurança recebidos em um prazo específico, bem como comunicar decisões sobre quais relatórios de vulnerabilidade são aceitos e corrigidos.
Exemplos
A <Name of your organization> tem o compromisso de trabalhar com pesquisadores de segurança para identificar e corrigir vulnerabilidades em nossos sistemas e serviços. Desde que você aja de boa-fé e cumpra as diretrizes descritas nesta política, faremos o possível para:- Enviar uma resposta inicial ao relatório de vulnerabilidade em até três dias úteis
- Determinar se vamos aceitar (pretende corrigir) ou rejeitar (identificar seu relatório como um falso positivo ou risco aceitável) seu relatório de vulnerabilidade em dez dias úteis
- Informar você sobre o progresso da correção dos relatórios aceitos
A adoção da linguagem safe Harbor na política do programa ajuda a garantir aos pesquisadores que nenhuma ação judicial será tomada contra eles para fazer testes nos seus sistemas, desde que eles ajam de boa-fé e sigam todas as diretrizes explicadas na política.
Diretrizes de teste
As diretrizes de teste descrevem os testes de segurança que estão no escopo do VDP, além dos testes que não estão no escopo e precisam ser evitados pelos pesquisadores. Se houver tipos específicos de vulnerabilidades que você quer que os pesquisadores se concentrem, esta seção é um bom lugar para destacá-las.
Exemplo:
Ao fazer um teste de segurança, siga estas
diretrizes:
- Teste apenas com suas próprias contas e dados (por exemplo, crie contas de teste). Se você identificar uma vulnerabilidade que pode resultar no acesso aos dados de outros usuários, fale conosco antes de testar mais.
- Se você acessar acidentalmente os dados de outros usuários nos testes, informe-nos e não armazene esses dados.
- Não realize testes que resultem em condições de negação de serviço ou degradação dos nossos serviços de produção.
- A engenharia social está fora do escopo deste programa. Não tente criar engenharia social na nossa organização ou nos nossos usuários.
Estamos especialmente interessados nos seguintes tipos de vulnerabilidades e impactos:
- Execução de código remoto
- XSS que resulta em acesso a dados sensíveis (por exemplo, informações da sessão)
- Injeção de SQL que resulta em acesso a funcionalidades ou dados sensíveis
- Falhas de lógica de negócios que resultam em acesso a funcionalidades ou dados sensíveis
Estamos menos interessados nos seguintes tipos de vulnerabilidade, que
têm mais probabilidade de
ser rejeitados como falsos positivos ou riscos aceitos:
- Falta do cabeçalho X-Frame-Options em páginas sem funcionalidade de alteração de estado
- Resultados não verificados do scanner automático
- Problemas com pouca probabilidade de exploração e/ou que não têm impacto realista na segurança
Escopo
O escopo define os recursos que os pesquisadores podem testar, bem como quais recursos não são considerados parte do VDP. O escopo precisa ser cuidadosamente considerado e ser o mais expansivo possível sem sobrecarregar sua equipe. Quanto mais você colocar no escopo, maior será a probabilidade de receber engajamento de pesquisadores de segurança. No entanto, não deixe o escopo tão expansivo a ponto de sua equipe não conseguir acompanhar os relatórios que chegam. Comece com alguns recursos no escopo. Expanda o escopo conforme você tem uma ideia melhor do volume de relatório que receberá. Antes de abrir seu VDP ao público, procure verificar se tudo está no escopo.
Em termos de como definir o escopo na Política do Programa, adicionar detalhes sobre cada recurso ou área ajuda os pesquisadores de segurança a saber o que é importante para você e onde concentrar os esforços. Você também pode incluir dicas sobre como testar seus recursos com segurança. Confira um exemplo:
| Asset | mail.example.com |
|---|---|
| Descrição | Domínio principal para os usuários acessarem o e-mail. |
| Vulnerabilidades e impactos interessantes |
|
| Problemas que provavelmente serão rejeitados |
|
| Diretrizes de teste | Só faça testes usando contas de sua propriedade ou que tenham consentimento expresso para isso. Ao criar contas de teste, inclua "vdptest" em algum lugar do nome de usuário. Você pode criar contas de teste em mail.example.com/new. |
Essa é uma análise bastante detalhada. Como alternativa, é possível incluir uma lista simples de recursos dentro e fora do escopo:
No escopo
- mail.example.com
- example.com
Fora do escopo
- blog.example.com
Terceirizar seu VDP
Você vai precisar de certos recursos antes de lançar um VDP. Você precisará de recursos para:
- Análise de relatórios de vulnerabilidade recebidos
- Comunicação com hackers
- Como encontrar proprietários de recursos e registrar bugs
- Como corrigir bugs
- Gerenciamento de vulnerabilidades / acompanhamento de correções
Revisitar as principais partes interessadas
Se você ainda não tiver feito isso, reveja as conversas com as principais partes interessadas com quem discutiu seu VDP anteriormente para garantir que elas estejam alinhadas com o cronograma de lançamento do VDP, bem como enfileirando todos os recursos necessários para o lançamento. Por exemplo, talvez você queira trabalhar com a liderança em engenharia para garantir que as equipes estejam prontas para um possível fluxo de bugs de segurança para trabalhar nas primeiras semanas após o lançamento. Dentro da equipe de segurança, verifique se os alertas de triagem nos sistemas de detecção e resposta estão cientes da data de lançamento do VDP e considere alocar mais tempo e recursos para quando o teste começar. Você também vai precisar formar uma equipe para dar suporte às operações diárias do VDP.
Crie sua equipe
A execução de um VDP requer uma quantidade considerável de trabalho operacional e acionado por interrupções. Se você tentar analisar, validar tecnicamente e responder a todos os relatórios de vulnerabilidade que receber, bem como registrar todos os bugs, acompanhar os status e comunicar atualizações aos pesquisadores por conta própria, você poderá se esgotar. Mesmo que você não tenha uma equipe de segurança grande, encontre voluntários dedicados à segurança para ajudar a criar uma equipe e operacionalizar e executar seu VDP. Você ainda vai precisar de um "proprietário" ou "líder" definido do VDP que seja responsável pelo sucesso do VDP, mas também precisará de uma equipe que apoie esse líder.
Criar um cronograma de serviço
Depois de ter recursos a bordo e dispostos a ajudar no VDP, crie um cronograma de serviço. É possível criar isso como quiser, mas a rotação semanal é uma prática bastante comum. Quando você está na ativa durante a semana, é sua responsabilidade:
- Triagem: analise os relatórios de vulnerabilidade recebidos.
- validar tecnicamente o relatório e tomar uma decisão de "aceitar" ou "rejeitar"
- Comunicar sua decisão ao hacker que relatou o problema
- Se necessário, peça mais informações ao hacker se não for possível reproduzir o problema
- Se a vulnerabilidade for válida, registre um bug aparado com o proprietário correto
- Gerenciamento de vulnerabilidades: promover vulnerabilidades
atuais
- Revise os bugs registrados nas últimas semanas de serviço para garantir que a correção progrida com base nos seus padrões de gravidade e cronogramas de correção.
- Usar as dicas de como encontrar proprietários para persuadir os proprietários a trabalhar nesses bugs
- Comunicação: forneça atualizações aos pesquisadores de segurança sobre
relatórios existentes
- Os pesquisadores podem solicitar atualizações sobre os relatórios de forma proativa e responder conforme necessário
- Se uma vulnerabilidade for corrigida, comunique isso ao pesquisador para que ele saiba que o trabalho árduo resultou em mudanças positivas na organização. É possível até mesmo incluir uma linguagem de modelo para que o pesquisador informe se você deixou de fazer algo na correção ou se ela pode ser ignorada de alguma forma.
Dependendo de quantos relatórios você recebe, da complexidade deles, e das habilidades e do conhecimento do funcionário, estar de serviço pode levar de algumas horas a uma semana inteira. Confira algumas dicas para uma rotação de serviço bem-sucedida:
- Certifique-se de que sua equipe esteja pronta para intervir e ajudar a apoiar o serviço em semanas particularmente pesadas.
- Tenha um bom processo de transferência. Se houver problemas que possam exigir atenção imediata da próxima pessoa em serviço, escreva algumas notas de transferência ou tenha uma conversa ao vivo no final da semana.
- Crie programações automatizadas para garantir que todos saibam quando estão em serviço. Isso pode ser tão simples quanto criar entradas de agenda recorrentes para cada indivíduo.
- Especialmente no início do VDP, verifique com a pessoa em serviço para confirmar se ela se lembra da semana dela e se ela precisa de ajuda. Se você tiver mais recursos juniores na rotação, peça para os mais seniores trabalharem com eles para garantir que eles se sintam confortáveis e possam fazer perguntas à medida que avançam.
- Tenha um processo flexível de troca de semanas. Inevitavelmente, alguém terá uma emergência e precisará de uma folga durante a semana ou tirará férias etc. Quando isso acontecer, incentive a equipe a trocar as semanas conforme necessário para acomodar a agenda de todos.
- Crie uma "folha de referência" que descreva as tarefas que precisam ser cobertas, incluindo a documentação sobre como fazer isso.
Defina se uma ideia é interna ou de terceiros.
A maior parte da orientação até agora foi baseada na criação e execução do VDP internamente. Há vários serviços de consultoria e plataformas disponíveis para ajudar você a criar e executar um VDP. Esses terceiros geralmente têm um custo, mas podem ser úteis para orientar você sobre a criação, lançamento e execução do VDP. Alguns oferecem serviços de triagem para ajudar a analisar os relatórios de vulnerabilidade recebidos, ajudando a lidar com a comunicação com os hackers e apenas encaminhando relatórios válidos para sua equipe. A decisão de criar esse processo internamente ou usar uma plataforma de terceiros dependerá de seus requisitos e dos recursos disponíveis. Se você tem um grande orçamento, mas não muito funcionário, pode usar um terceiro para ajudar a executar seu programa. Se for o contrário, pode valer a pena investir o tempo para criar seu programa por conta própria.
Recebimento de relatórios
Se você decidir usar uma plataforma de terceiros, ela precisa oferecer uma maneira para que os hackers enviem relatórios diretamente a você. Se você criar seu programa internamente, precisará criá-lo por conta própria. Pode ser um endereço de e-mail que cria automaticamente um tíquete ou bug no Issue Tracker (por exemplo, security@example.com) ou pode ser um formulário da Web com campos de formulário obrigatórios vinculados ou na mesma página da Política do Programa. Seja qual for o formato, esta é a melhor chance de informar aos hackers o formato em que você quer receber os relatórios. Pedir para os hackers enviarem relatórios em um determinado formato nem sempre garante que isso será feito, mas não faz mal perguntar. Confira um exemplo do que você pode pedir em um formulário de envio de relatório:
Title: [Adicione uma descrição de uma linha do problema, por exemplo, "XSS em
mail.example.com"
resulta em roubo de sessão"]
1)
2.
3.
Cenário de ataque e impacto: [como isso pode ser explorado? Qual é o impacto
na segurança desse
problema?]
Recomendação de correção: [opcionalmente, se você tiver alguma dica sobre como
esse problema pode ser corrigido ou corrigido, adicione aqui.]