Preparação

Nesta seção, discutiremos em detalhes como preparar sua organização para lançar e executar um programa de divulgação de vulnerabilidades bem-sucedido, incluindo orientações práticas sobre como preencher as lacunas identificadas.

Como encontrar bugs

Incentivar seu programa de segurança atual com pesquisadores de segurança externos é uma ótima maneira de encontrar problemas complexos e ocultar vulnerabilidades. No entanto, usar um VDP para encontrar problemas básicos de segurança que podem ser descobertos internamente é um desperdício de recursos.

Gerenciamento de ativos

Quando se trata de encontrar bugs, a única maneira de saber por onde começar é se tiver uma boa ideia do que existe. É possível comprar centenas de ferramentas de segurança, mas isso não fará diferença se as equipes estiverem mantendo aplicativos, sistemas e serviços ad hoc sem seu conhecimento, especialmente se você não tiver como descobrir e realizar avaliações de segurança nesses recursos. Verifique com as pessoas e equipes responsáveis por ajudar a criar novos aplicativos, sistemas e serviços para ver se eles têm um processo para criar e manter um inventário do que está sendo acrescentado e quem é o proprietário. Caso não haja um processo atual, esta é uma ótima oportunidade de colaborar com essas equipes para criar um. Entender os recursos da sua organização é o melhor ponto de partida para identificar a superfície de ataque. Como parte desse processo, a equipe de segurança precisa estar envolvida no desenvolvimento de uma nova implementação de infraestrutura para realizar avaliações de segurança. É uma boa prática ter um extenso inventário de recursos e proprietários. Esse tipo de inventário é útil ao aplicar novos patches que exigem a desativação de determinados sistemas temporariamente. Ela oferece um roteiro de indivíduos ou equipes que precisam ser informadas e quais sistemas são afetados. Ter um processo robusto de gerenciamento de recursos garante que os proprietários sejam identificados no início do processo, atualizados regularmente e que todos os sistemas da organização operem conforme o esperado.

Além do gerenciamento proativo de recursos, pense em quais medidas reativas também é possível implementar para identificar recursos que pertencem à sua organização, mas que você filtrou nos processos padronizados de gerenciamento de recursos. Isso pode incluir o uso dos mesmos processos de "reconhecimento" usados por pesquisadores de segurança que participam de VDPs e programas de recompensa por bugs. Por exemplo, é possível aproveitar ferramentas sem custo financeiro e de código aberto que verificam e enumeram intervalos ou domínios de IP voltados à Internet que possam pertencer à sua organização. Uma pesquisa no Google por bug recon (reconhecimento de recompensas de bugs) produzirá uma variedade de dicas e truques para ajudar você a identificar recursos da sua organização que você não conhecia.

Verificação básica de vulnerabilidades

Agora que você tem uma base sólida onde precisa encontrar problemas de segurança, vamos ver como fazer isso. Há vários níveis de profundidade, dependendo dos recursos da organização, mas você precisa encontrar um equilíbrio entre os esforços internos de segurança e a comunidade externa de hackers por meio do programa de divulgação de vulnerabilidades. Esse equilíbrio é diferente para cada organização, dependendo dos recursos disponíveis.

Escolher suas ferramentas

Há muitas ferramentas diferentes para ajudar na identificação de vulnerabilidades. Algumas ferramentas de verificação de vulnerabilidades estão disponíveis sem custo financeiro, enquanto outras têm um custo. Descobrir quais ferramentas escolher depende de suas necessidades individuais.

• Requisitos da sua organização
• Se cada ferramenta atende a esses requisitos
• Se os benefícios da ferramenta superam os custos (financeiros e de implementação).

É possível usar este modelo de requisitos (OpenDocument .ods, Microsoft Excel .xlsx) para avaliar várias ferramentas de acordo com seus requisitos. Alguns exemplos de requisitos estão incluídos no modelo, mas você precisa discutir com as equipes de segurança, TI e engenharia para alinhar os recursos necessários. Antes de lançar um programa de divulgação de vulnerabilidades, é necessário ser capaz de realizar verificações de vulnerabilidade em relação a recursos externos, como sites, APIs e apps para dispositivos móveis. Isso ajudará você a encontrar e corrigir vulnerabilidades facilmente detectáveis antes de convidar pesquisadores de segurança externos para testarem esses recursos e serviços.

Configuração da verificação

As verificações automáticas de vulnerabilidades podem encontrar muitos problemas, mas também podem produzir falsos positivos. Por isso, é necessário ter recursos para validar os resultados antes de compartilhá-los com as equipes afetadas. Você precisará implementar processos para garantir que as verificações sejam executadas regularmente e que os resultados sejam realmente analisados. Isso será diferente para cada organização, mas, no mínimo, você precisa determinar:

• Frequência de verificação
  • Contínuo
  • Semanalmente
  • Mensal
• Quais recursos estão sendo verificados
• Credenciais
  • Verificações autenticadas vs. não autenticadas
  • Dica: se você não fizer a verificação com credenciais, um pesquisador de segurança testará com credenciais quando você iniciar o VDP. É possível que você tenha um grande pico de vulnerabilidades identificadas.
• Funções e responsabilidades
  • Identifique os membros da equipe responsáveis por executar as verificações
  • Configure uma rotação, se necessário
• Resultados da verificação
  • Como verificar os resultados da verificação
  • Como informar bugs para vulnerabilidades verificadas
  • Como identificar proprietários para corrigir bugs
  • Acompanhamento com os proprietários sobre a correção

Veremos em mais detalhes como garantir que os problemas de segurança identificados sejam corrigidos na seção Como corrigir bugs mais adiante neste guia.

Processo de análise de segurança

Embora a verificação de vulnerabilidades seja uma ótima maneira de identificar de maneira reativa os problemas de segurança na sua organização, a implementação de processos de análise de segurança pode ajudar a evitar que vulnerabilidades sejam introduzidas. Para os fins deste guia, o termo análise de segurança refere-se a qualquer situação que aciona uma análise manual por um membro da sua equipe de segurança. Normalmente, isso inclui ter autoridade para bloquear uma mudança se for considerado muito arriscado. Caso sua equipe de segurança não tenha a capacidade de bloquear mudanças arriscadas, ainda convém ter processos para documentar o risco. Isso ajuda a garantir que a pessoa que está impulsionando a mudança conheça o risco envolvido e aceite esse risco proativamente.

Critérios da análise de segurança

Quando as análises de segurança devem acontecer? A criação de um conjunto de critérios que aciona uma revisão de segurança ajuda a garantir que todos estejam na mesma página. Veja abaixo alguns exemplos de cenários que podem acionar uma análise de segurança.

• Foi proposta uma nova funcionalidade relacionada aos dados confidenciais do usuário
  • Um novo recurso que permite aos usuários compartilhar a localização no mapa
  • Solicitar informações potencialmente sensíveis dos usuários, como endereço de casa, data de nascimento ou número de telefone
• Foram feitas atualizações importantes nas funcionalidades existentes
  • Utilizar os dados do usuário de uma maneira inesperada sem dar a eles a oportunidade de recusar
  • alterações em qualquer recurso relacionado à autenticação, autorização e gerenciamento de sessões;
• Alterações no ambiente de produção da empresa
  • Mudanças na configuração de rede, especialmente aquelas que podem resultar na exposição externa dos serviços.
  • Instalação de novo software que lida com dados sensíveis de usuários que, se comprometido, poderá ser usado indiretamente para acessar esses dados
  • Colocar novos sistemas ou serviços
• Interagir com um novo fornecedor ou mudar o modo como você trabalha com um fornecedor atual
  • Integrar um novo fornecedor que vai lidar com dados sensíveis do usuário
  • Mudanças na forma como você trabalha com um fornecedor atual, que fazem com que o fornecedor processe dados confidenciais do usuário

Esta não é uma lista completa, mas deve fazer você pensar sobre quais tipos de alterações precisam de uma análise de segurança. Ao definir os critérios do que precisa ou não de uma análise de segurança, converse com as principais partes interessadas em toda a organização para garantir que:

• As partes interessadas têm a chance de analisar e fornecer feedback sobre os critérios
• As partes interessadas concordam com os critérios
• As partes interessadas concordam em solicitar proativamente revisões de segurança

Documente esses critérios e explique como solicitar uma análise de segurança. Por exemplo, registrar um bug em uma fila monitorada pela equipe de segurança para facilitar o processo para sua organização.

Recursos para análise de segurança

Ao contrário das verificações automáticas, as revisões de segurança exigem mais recursos. Cada equipe de segurança só tem muito tempo no dia para realizar uma infinidade de tarefas. Por isso, é necessário estimar quantas avaliações de segurança podem ser geradas com base nos seus critérios. Se você achar que a equipe está sobrecarregada e ficando para trás, os que estão esperando o lançamento dos recursos ficarão chateados com a equipe de segurança. Isso pode causar uma mudança cultural na organização, fazendo com que a equipe de segurança seja vista como um bloqueador em vez de um parceiro. Se o processo de análise de segurança não for eficiente, muitos indivíduos e equipes tentarão ignorá-lo completamente. Se os recursos estiverem escassos, considere flexibilizar os critérios para exigir uma análise de segurança e esteja disposto a aceitar mais riscos residuais. Se ocorrerem incidentes como resultado da falta de recursos para realizar análises de segurança, isso ajudará a justificar a necessidade de mais recursos de segurança.

Realizar análises de segurança

Quando se trata de decidir sobre quais análises de segurança realizar e como realizá-las, você vai precisar de uma fila priorizada para extrair. Crie uma maneira padronizada para outras pessoas em sua organização solicitarem uma análise de segurança com as informações necessárias para priorizá-la adequadamente. Por exemplo, considere um questionário que inclua itens como a natureza da alteração, incluindo um breve resumo da alteração e quais tipos de dados do usuário podem ser afetados. É possível categorizar automaticamente as possíveis análises de segurança em mudanças de alto, médio ou baixo risco com base nas respostas a essas perguntas. Se uma mudança for de alto risco, talvez seja necessário passar por um processo de análise de segurança mais detalhado. Se uma alteração for de menor risco, você poderá implementar um processo de análise de segurança mais leve para ajudar a reduzir os recursos necessários e acelerar o processo, permitindo melhor os negócios. Configure uma rotação com sua equipe para ser responsável por gerenciar a fila de análise de segurança, garantindo que as novas análises de segurança sejam selecionadas pelos membros da equipe e acompanhando o progresso das análises de segurança existentes. O processo real de análise de segurança varia de acordo com o que está sendo examinado. Por exemplo, um novo recurso no seu app para dispositivos móveis pode exigir que um engenheiro de segurança analise o código e procure possíveis vulnerabilidades. Talvez o novo software instalado precise ser revisado para garantir que o controle de acesso esteja configurado corretamente. Trabalhar com fornecedores externos pode ser um processo completamente diferente. Como referência, leia o Questionário de avaliação de segurança do fornecedor do Google.

Como corrigir bugs

Encontrar bugs é importante, mas a segurança só melhora depois que eles são corrigidos. Saber quais riscos existem para sua organização é bom, mas ser capaz de resolvê-los com eficiência é melhor.

Gerenciamento de vulnerabilidades

As vulnerabilidades são originadas de diversos recursos, incluindo esforços internos (por exemplo, verificações de vulnerabilidades e revisões de segurança), testes e auditorias de penetração de terceiros ou até mesmo pesquisadores de segurança externos que notificam você por canais de suporte antes do lançamento oficial do VDP. Sua organização precisa de uma maneira de categorizar vulnerabilidades novas e atuais para garantir que elas sejam comunicadas às partes interessadas certas, priorizadas corretamente e corrigidas em tempo hábil. Ao iniciar o VDP, você terá um novo fluxo de vulnerabilidades entrando nos processos de gerenciamento de vulnerabilidades. Ter processos sólidos para lidar com essas vulnerabilidades ajuda a acompanhar o progresso da remediação e responder às solicitações de atualizações de pesquisadores de segurança externos. Ser capaz de priorizar rapidamente uma vulnerabilidade e se comunicar com os participantes do VDP sobre o cronograma de correção aumenta o envolvimento com a comunidade de pesquisadores de segurança, além de melhorar a reputação da segurança da sua organização. As seções a seguir descrevem vários aspectos do programa de gerenciamento de vulnerabilidades que precisam ser implementados antes de lançar o VDP.

Estabelecer padrões de gravidade e cronogramas de correção

Criar uma linguagem comum para a gravidade das vulnerabilidades e os cronogramas de correção ideais associados a cada gravidade facilita a definição das expectativas padrão da organização. Se cada vulnerabilidade for tratada como uma emergência, a organização vai esgotar os recursos e ficar ressentido em relação à equipe de segurança. Se todas as vulnerabilidades forem consideradas de baixa prioridade, elas nunca serão corrigidas, e o risco de violação aumenta. Cada organização tem recursos limitados, então será necessário estabelecer uma classificação de gravidade. Essa classificação fornece critérios que ajudam a organização a entender a gravidade de uma vulnerabilidade e os cronogramas de correção esperados associados a cada uma delas. Esboce um conjunto de diretrizes de gravidade e compartilhe com as principais partes interessadas em sua organização para receber feedback. Por exemplo, se a engenharia estiver envolvida na criação dos padrões de gravidade, ela provavelmente vai se envolver com esses padrões e aderir a eles quando chegar a hora de corrigir uma vulnerabilidade dentro de um período especificado. Essas diretrizes de gravidade podem variar dependendo dos riscos específicos para sua empresa. É recomendável considerar um exercício de modelagem de ameaças para pensar sobre quais ameaças são mais prováveis e impactantes para sua organização e incluir exemplos de problemas que se enquadrariam em cada categoria de gravidade. Veja abaixo um exemplo de padrões de gravidade e cronogramas de correção para uma organização financeira.

Gravidade	Descrição	Cronograma de correção	Exemplos
Crítico	São problemas que representam uma ameaça iminente para nossos usuários ou nossa empresa.	Proprietário : para garantir que a vulnerabilidade seja corrigida, o proprietário principal precisa ser identificado dentro de 8 horas. Ligue e envie mensagens conforme necessário, mesmo fora do horário comercial normal. Correção:o problema precisa ser corrigido ou pelo menos ter o risco mitigado o mais rápido possível ou, no máximo, em até três dias úteis.	Comprometimento de um banco de dados de produção, incluindo os registros financeiros de todos os usuários. Um invasor que consegue acesso a segredos comerciais, como nossos algoritmos de investimento reservados. Um incidente ativo, incluindo um invasor que consegue acesso à nossa rede interna ou a sistemas de produção confidenciais.
Caro	Problemas que, se explorados, podem causar danos significativos.	Proprietário:o proprietário principal precisa ser identificado em até um dia útil. Correção:em até 10 dias úteis (aproximadamente 2 semanas).	Vulnerabilidades que podem resultar no acesso a recursos ou dados confidenciais do usuário, como a capacidade de qualquer usuário roubar fundos de outro.
Médio	São problemas mais difíceis de explorar ou que não resultam em danos diretos.	Proprietário:o proprietário principal precisa ser identificado em até cinco dias úteis. Correção:em até 20 a 40 dias úteis (cerca de 1 a 2 meses).	Problemas verificados identificados por verificadores automatizados, como patches de atualizações de segurança sem explorações conhecidas. Problemas de divulgação de informações que provavelmente ajudariam em ataques futuros. Problemas de limitação de taxa que poderiam ser explorados (por exemplo, conseguir adivinhar as senhas de um usuário continuamente).
Baixo	Problemas com impacto mínimo. Usado principalmente para registrar problemas conhecidos.	Não há requisitos para encontrar um proprietário ou corrigir o problema dentro de um cronograma especificado.	Divulgação de informações que não apresentam risco provável, mas que não precisam estar acessíveis externamente.

Insetos no processo de higiene

Não estamos falando de cortes de cabelo aqui, mas de garantir que os bugs sejam formatados corretamente para que possam ser facilmente corrigidos. Usando a tabela anterior como diretriz, estabeleça suas próprias definições de gravidade. Essas definições são usadas para classificar bugs em várias gravidades e comunicá-los aos proprietários.

Além de atribuir uma gravidade a cada vulnerabilidade, é preciso garantir que os bugs estejam em um formato padrão que facilite o recebimento das equipes. As vulnerabilidades entrarão nos seus processos de gerenciamento de vulnerabilidades em vários formatos, como resultados de verificação automatizada ou gravações manuais de análises de segurança. Reservar um tempo para converter cada vulnerabilidade em um formato padrão aumentará as chances de a equipe de recebimento entender e resolver o problema rapidamente.

Esse formato ou modelo pode variar dependendo da sua organização e das informações mais pertinentes para ajudar os proprietários a corrigir bugs atribuídos a eles, mas aqui está um exemplo de modelo que você pode usar. Você poderá reutilizar esse modelo mais tarde, quando criar o formulário de envio do Programa de divulgação de vulnerabilidades para pesquisadores.

Título: <descrição em uma linha do problema, geralmente o tipo de vulnerabilidade e qual recurso/serviço/etc. foi afetado Como opção, inclua a gravidade ou mapeie a gravidade para um campo no Issue Tracker> Resumo: <breve descrição da vulnerabilidade e por que ela é importante> Etapas de reprodução: <instruções passo a passo sobre como mostrar a existência da vulnerabilidade com qualquer outro risco

Veja um exemplo de vulnerabilidade de alta gravidade potencial:

Título: [HIGH] Referência de objeto direto inseguro (IDOR, na sigla em inglês) em páginas de perfil Resumo: foi encontrado um IDOR na funcionalidade das páginas de perfil do nosso app que permitia a qualquer usuário ter acesso não autorizado a visualizar e editar o perfil de outro usuário, incluindo o nome completo, endereço residencial, número de telefone e data de nascimento do outro usuário. Analisamos os registros e Parece que esse problema ainda não foi explorado. Esse problema foi descoberto internamente. Etapas de reprodução:

1. Configure um proxy, por exemplo, o Burp Suite, para interceptar o tráfego em um dispositivo móvel com o app instalado.
2. Visite a página do seu perfil e intercepte a solicitação HTTP associada.
3. Modifique profileID=###### para ser profileID=000000 (este é um usuário de teste) e envie a solicitação HTTP.
4. O aplicativo mostrará o perfil do usuário 000000, e você poderá visualizar e editar as informações dele.

Cenário / impacto de ataque:qualquer usuário pode usar essa vulnerabilidade para visualizar e editar o perfil de outro. Na pior das hipóteses, um invasor poderia automatizar o processo de recuperação das informações de perfil de cada usuário em todo o sistema. Embora ainda não acreditemos que isso tenha sido explorado, é importante tratar isso como um problema padrão de gravidade ALTA. Se observarmos evidência de exploração, isso pode levar a uma gravidade Crítica. Etapas de correção:implemente verificações no lado do servidor para garantir que o usuário que fez a solicitação tenha acesso para visualizar/editar o perfil solicitado pelo valor de profileID. Por exemplo, se Alice estiver conectada e tiver o profileID 123456, mas perceber que Alice solicitou o profileID 333444, o usuário verá um erro e essa tentativa de acessar o perfil de outro usuário será registrada. Para mais informações sobre o IDOR e como corrigi-lo, consulte os materiais do OWASP sobre esse bug (link em inglês).

Você pode economizar tempo e esforço manual encontrando maneiras de automatizar a conversão de vulnerabilidades de várias fontes para o formato padrão. À medida que você criar mais vulnerabilidades, poderá encontrar temas comuns nas etapas de correção. Além do modelo genérico de formato de bug, crie outros modelos para tipos de vulnerabilidade comuns.

Encontrar proprietários

Talvez um dos aspectos mais difíceis do gerenciamento de vulnerabilidades seja identificar os responsáveis para ajudar a corrigir bugs, além de conseguir a adesão deles para dedicar recursos à correção de bugs dentro do prazo. Se você tiver configurado processos de gerenciamento de recursos, isso será um pouco mais fácil. Caso contrário, isso pode servir como motivação para fazer isso. Dependendo do tamanho da sua organização, encontrar um proprietário pode ser bastante simples ou incrivelmente complexo. À medida que sua organização cresce, o esforço para determinar quem é responsável por corrigir problemas de segurança recém-descobertos também aumenta. Considere a implementação de uma rotação de serviço operacional. A pessoa na equipe é responsável por revisar vulnerabilidades não atribuídas, rastrear proprietários e priorizar com base na gravidade. Mesmo que você consiga identificar quem é responsável por corrigir uma vulnerabilidade e atribuí-lo ao bug, também será necessário convencê-lo a investir tempo na correção dela. Essa abordagem pode variar de acordo com a equipe ou o indivíduo e que outros itens em que ele está trabalhando. Se você alcançou aderência organizacional nos seus padrões de gravidade e cronogramas de correção, poderá consultar esses dados, mas às vezes pode ser necessário persuasão extra para que alguém corrija um bug. Confira algumas dicas gerais para corrigir vulnerabilidades:

• Explique o motivo: quando alguém recebe uma vulnerabilidade para corrigir, o resultado costuma ser um trabalho inesperado. Explique por que esse problema é importante ser corrigido em tempo hábil (por exemplo, impacto / cenário de ataque) e garante que o proprietário entenda o problema.
• Colete contexto: em alguns casos, apenas uma pessoa tem o conhecimento necessário para corrigir um bug e pode ter outras tarefas em que está trabalhando. Reserve um tempo para descobrir o que é isso. É possível que as outras tarefas sejam mais importantes do que a correção dessa vulnerabilidade a curto prazo. Demonstrar empatia e flexibilidade nos cronogramas de correção ajuda a ter boa vontade e fortalecer seu relacionamento com as pessoas que você precisa corrigir vulnerabilidades. Só tome cuidado para não dar muito espaço de manobra. Caso contrário, sua organização não vai levar os cronogramas de correção a sério.
• Explique como:mesmo que você inclua conselhos de correção no bug, o proprietário da correção pode ficar confuso ou precisar de ajuda para aprender a corrigir o bug. Se eles precisarem de ajuda para descobrir como corrigir o problema, ajude a ensiná-los. Simplesmente jogar bugs nos proprietários sem ajudá-los vai prejudicar o relacionamento da organização com a equipe de segurança. Ajudar os outros o máximo possível os capaz de corrigir vulnerabilidades atuais e futuras, bem como de ensinar outras pessoas.
• Adapte sua solicitação: várias equipes e indivíduos podem ter processos para definir como aceitam e priorizam as solicitações de trabalho recebidas. Algumas equipes podem querer que todas as solicitações recebidas passem pelos gerentes. Outros querem que as solicitações de ajuda sejam enviadas em um formato padrão. Algumas só funcionarão no que foi predefinido em um sprint. Seja qual for o caso, dedicar um tempo extra para adaptar a solicitação ao formato que a equipe ou o indivíduo geralmente usa para receber solicitações de ajuda aumentará a probabilidade de que sua solicitação seja priorizada e realizada.
• Encaminhe como último recurso: se você já tentou todas as opções acima e a pessoa ou a equipe responsável por corrigir uma vulnerabilidade simplesmente não se esforça para corrigir um problema grave de segurança, considere escalar para a liderança conforme necessário. Esse deve ser sempre um último recurso, já que pode prejudicar seu relacionamento com a pessoa ou a equipe em questão.

Análise da causa raiz

Além de encontrar e corrigir vulnerabilidades individuais, a análise da causa raiz (RCA, na sigla em inglês) pode ajudar a identificar e resolver problemas de segurança sistêmicos. Todos têm recursos limitados, então é tentador pular essa etapa. No entanto, investir tempo na análise de tendências nos seus dados de vulnerabilidade, bem como analisar bugs críticos e de gravidade alta, pode economizar tempo e reduzir o risco a longo prazo. Por exemplo, digamos que você perceba que o mesmo tipo de vulnerabilidade (por exemplo, redirecionamento de intents) aparece repetidamente em todo o app. Você decide conversar com as equipes que estão introduzindo essa vulnerabilidade no app e percebe que a grande maioria delas não entende o que é o redirecionamento de intents, por que é importante ou como evitá-lo. Você organiza uma palestra e um guia para ajudar a educar os desenvolvedores em sua organização sobre essa vulnerabilidade. Essa vulnerabilidade provavelmente não desaparecerá completamente, mas a taxa em que ela aparece provavelmente diminuirá. Quando você inicia o VDP, toda vulnerabilidade informada por terceiros é algo que passou pelos processos de segurança internos atuais. Realizar RCA em bugs do VDP fornecerá ainda mais insights sobre como melhorar sistematicamente o programa de segurança.

Detecção e resposta

Detecção e resposta se referem a todas as ferramentas e processos que você tem para detectar e responder a possíveis ataques contra a organização. Isso pode vir na forma de soluções compradas ou autodesenvolvidas que analisam dados para identificar comportamentos suspeitos. Por exemplo, na seção Grooming Bugs, falamos sobre o registro sempre que um usuário tenta ter acesso não autorizado ao perfil de outro usuário. Você pode ter um sinal ou alerta gerado se perceber que um usuário gera um grande número de tentativas com falha de acessar os perfis de outro usuário em um curto período. É possível até mesmo automatizar o processo de bloqueio do acesso desse usuário a qualquer um dos seus serviços por um determinado período ou indefinidamente até que a situação possa ser analisada e restaurar o acesso manualmente. Se você ainda não tiver mecanismos de detecção e resposta, trabalhe com um consultor especializado para orientar sobre como criar um programa de análise forense digital e resposta a incidentes (DFIR, na sigla em inglês) para sua organização. Se você já tem mecanismos de detecção e resposta, considere as consequências de ter cinco, dez ou até cem pesquisadores de segurança testando as superfícies de ataque da Internet. Isso pode ter um grande impacto em qualquer sistema de detecção e prevenção de intrusões (IDS/IPS, na sigla em inglês) que você tiver.

Os riscos potenciais incluem:

• Sobrecarga de alertas:uma enxurrada de alertas ou sinais que parecem ataques maliciosos, mas são testes normais e aprovados por pesquisadores de segurança que participam do VDP. É possível gerar tanto ruído, que fica difícil distinguir ataques reais de testes de segurança legítimos.
• Alarmes falsos de resposta a incidentes: se você tiver processos que avisam os indivíduos às 2h de sábado, eles não ficarão satisfeitos em acordar e investigar uma possível violação que era, na verdade, apenas um pesquisador de segurança realizando testes legítimos.
• Bloqueio de pesquisadores de segurança: se você tiver IPS (sistemas de prevenção de intrusões) agressivos, é possível que você acabe bloqueando o endereço IP de um pesquisador de segurança que está tentando executar verificações, testes manuais etc. para identificar vulnerabilidades e informá-las a você. Especialmente no caso de um VDP, se um pesquisador de segurança é bloqueado após cinco minutos de teste, ele pode perder o interesse e, em vez disso, se concentrar no programa de outra organização. Isso pode resultar em uma falta geral de engajamento dos pesquisadores de segurança no seu programa, o que aumenta o risco de vulnerabilidades não serem descobertas (ou, portanto, desconhecidas para sua organização). Mesmo que não seja recomendado diminuir o IPS em si, há outras medidas que você pode tomar para reduzir o risco de desencorajar os pesquisadores.

A forma de lidar com esses riscos depende muito da abordagem que você quer adotar para trabalhar com pesquisadores de segurança externos. Se você quiser um estilo de teste com mais caixa preta que simula ataques reais, você poderá não fazer nada. Nesse caso, o tráfego do pesquisador vai gerar alertas, e sua equipe poderá tomar medidas para investigar e responder de acordo. Isso ajudará sua equipe a praticar a resposta a ataques reais, mas poderá diminuir o engajamento com os pesquisadores de segurança, especialmente se eles forem bloqueados nos testes. Também pode resultar na perda de um ataque real e, ao mesmo tempo, passar tempo investigando testes legítimos. Se você quiser uma abordagem de caixa cinza, considere trabalhar com os pesquisadores de segurança para identificar automaticamente o tráfego de teste de alguma forma. Assim, você poderá colocar na lista de permissões ou filtrar o tráfego dos testes e dos alertas resultantes. Sua equipe poderá distinguir melhor ataques reais de testes aprovados, e os pesquisadores poderão encontrar e informar vulnerabilidades para você sem serem impedidos por seus sistemas de prevenção de invasões. Algumas organizações pedem aos pesquisadores de segurança que enviem um formulário para solicitar um identificador exclusivo, que pode ser anexado aos cabeçalhos nas solicitações geradas pelo pesquisador. Isso permite que a organização coloque o tráfego do pesquisador na lista de permissões, bem como a capacidade de identificar se o pesquisador começa a ir além do escopo acordado de testes. Se isso acontecer, entre em contato com o pesquisador e peça que ele adie até que vocês possam trabalhar juntos em um plano de teste.