Imagine que você é o gerente de cibersegurança de uma empresa que possui o site www.example.com. Um dia, o departamento de vendas recebe um e-mail de um indivíduo desconhecido e o encaminha para você. O conteúdo do e-mail é o seguinte:
Sua página example.com/login.php está quebrada. Enviando XSS.
Se não houver correção, eu envio para a FD em um mês.
O que está acontecendo? Você acabou de ser contatado por um hacker ético relatando uma vulnerabilidade de cross-site scripting (XSS) em seu site. Aqui estão os "o que fazer" e "o que não fazer" para lidar com a situação e evitar a divulgação pública não coordenada da vulnerabilidade - e para corrigir o problema de segurança em seus sistemas.
Passo 1. Adote a atitude certa
Em primeiro lugar, perceba que você não foi invadido. Se fosse um atacante, provavelmente você não seria notificado de forma tão educada e o impacto potencial seria muito maior. Na verdade, você pode ter descoberto o problema somente depois que sua página da web foi usada para atacar outra pessoa ou um de seus clientes entrou com uma ação judicial porque suas informações confidenciais foram divulgadas publicamente.
A pessoa que entrou em contato com você é um pesquisador de segurança independente, também conhecido como um hacker ético. Eles encontram problemas de segurança e os relatam de boa-fé, ganhando dinheiro por meio de recompensas por bugs.
O que fazer:
Tenha respeito pelo hacker. Eles entraram em contato com você para ajudar, não para prejudicá-lo.
Seja paciente. Eles podem não ser bons em se comunicar com empresas.
Eles podem não ser falantes nativos de inglês. Se possível, tente descobrir o idioma preferido deles e encontre alguém que possa ajudá-lo com a tradução.
Respeite a privacidade deles. Se eles insistirem em usar um apelido ou um proxy anônimo, não os pressione para revelar informações pessoais. Se eles usam PGP para criptografar e assinar suas mensagens, use a chave pública deles para criptografar suas respostas também. A privacidade é importante para os hackers porque nem todas as empresas são tão inteligentes quanto a sua, e muitas tomarão medidas legais mesmo contra hackers éticos, muitas vezes envolvendo a aplicação da lei.
Lembre-se de que se você não seguir o processo proposto e o hacker eventualmente divulgar publicamente sua vulnerabilidade, a responsabilidade será sua, não do hacker.
O que não fazer:
Não ignore a mensagem. Mesmo se você decidir corrigir o problema silenciosamente, ele pode ser divulgado publicamente antes de estar pronto.
Não tente cortar caminhos, ou você pode ganhar uma má reputação na comunidade de hackers, e outros hackers éticos não estarão dispostos a ajudá-lo com segurança no futuro.
Passo 2. Comunicar de forma eficiente
Para evitar divulgação pública não controlada de suas vulnerabilidades de segurança, certifique-se de que o hacker que reportou o problema está atualizado sobre o processo de correção. A razão pela qual eles relataram o problema e querem que seja corrigido o mais rápido possível é que outros usuários podem estar em perigo. Por exemplo, uma vulnerabilidade XSS em sua aplicação da web pode ser usada para phishing mais eficaz, permitindo que os invasores usem seu nome de domínio para ganhar confiança em truques de engenharia social.
O que fazer:
Delegue a responsabilidade corretamente. O e-mail original pode ter sido recebido por uma pessoa não técnica - talvez um contato de vendas ou marketing. Selecione um funcionário técnico, de preferência da equipe de segurança de TI, e faça com que eles sejam o ponto principal de contato para toda a comunicação com o hacker. Certifique-se de que essa pessoa saiba a atitude certa a adotar (veja o passo 1).
Certifique-se de que todos os seus funcionários saibam como escalar possíveis problemas de segurança e não ignorem tais relatórios. Treine a equipe em funções voltadas para o público sobre como lidar com relatórios de segurança, para quem encaminhá-los e quando ignorar o processo de escalonamento usado para consultas regulares.
Comunique-se de forma clara e regular. Mantenha o hacker atualizado sobre o progresso da correção. Responda imediatamente para confirmar que recebeu o relatório e está investigando. Forneça estimativas de tempo específicas, por exemplo, que você pretende concluir a pesquisa em cinco dias úteis.
Hackers éticos seguem práticas de divulgação responsável. Eles geralmente darão um prazo específico para corrigir uma vulnerabilidade antes de divulgá-la publicamente (um mês em nosso exemplo). Se eles não especificaram um prazo, pergunte sobre sua preferência e negocie o prazo, se necessário.
O que não fazer:
Não tenha medo de pedir ajuda ou informações adicionais. Se tiver problemas para confirmar a vulnerabilidade, peça ajuda ao hacker. Mesmo se tiver problemas para corrigir o problema, não fará mal pedir dicas ao hacker.
Não deixe o hacker esperando por atualizações. Se você prometeu investigar em sete dias e não cumpriu, certifique-se de entrar em contato com o hacker, se desculpar e fornecer uma nova estimativa de tempo.
.png)
Passo 3. Confirme a vulnerabilidade
Antes de corrigir, você deve confirmar a vulnerabilidade relatada e aprender mais sobre ela. Isso tornará o bug mais fácil de entender e corrigir.
O que fazer:
Use uma ferramenta de varredura automatizada de vulnerabilidades da web, como Invicti ou Acunetix by Invicti, para verificar rapidamente se a vulnerabilidade relatada é detectada. Se você executar varreduras com o recurso IAST ativo em seu servidor, também poderá obter informações adicionais sobre a localização exata da causa raiz em seu código-fonte ou bytecode.
Se precisar de mais informações para encontrar ou confirmar a vulnerabilidade, pode ser necessário delegar um dos seus engenheiros de segurança para investigar. Você também pode contratar uma empresa externa para realizar um teste de penetração ou investigar o problema.
O que não fazer:
Não assuma que a vulnerabilidade não existe só porque o seu scanner ou a sua equipe não consegue encontrá-la ou confirmá-la. Peça ajuda e mais detalhes ao hacker. Eles geralmente fornecem uma prova de conceito para ilustrar o problema (como no nosso exemplo) - peça uma se eles não a forneceram.
Passo 4. Remediar prontamente
Mesmo que a vulnerabilidade relatada não pareça muito perigosa, você deve priorizar a correção simplesmente porque o problema foi relatado por uma fonte externa e pode ser divulgado publicamente.
O que fazer:
Você pode muitas vezes aplicar uma solução temporária, como uma regra de firewall de aplicativo da web (WAF), para proteger seu sistema até que possa corrigir a vulnerabilidade. Os scanners da Invicti integram-se a vários produtos WAF e podem exportar regras, portanto, você pode até mesmo fazer isso automaticamente.
Se a vulnerabilidade foi encontrada em um código desenvolvido internamente, aproveite a correção como uma oportunidade para educar seus desenvolvedores sobre como evitar essas vulnerabilidades no futuro. A Invicti Learn é um recurso com muitas informações sobre compreensão, correção e prevenção de vulnerabilidades na web.
Depois de concluído, peça ao hacker que relatou o problema para confirmar a correção.
O que não fazer:
Não pense que uma vulnerabilidade não é um problema seu se ela estiver em um software de terceiros. Se uma correção não estiver disponível por parte do terceiro, você pode ter que solicitar ao fornecedor ou criar sua própria correção dedicada (normalmente para software de código aberto). Vulnerabilidades zero-day em softwares de terceiros populares geralmente são as mais perigosas, pois podem afetar várias organizações, então hackers mal-intencionados tentam explorá-las primeiro.
Não trate a mitigação temporária como uma correção permanente. Uma regra de WAF pode bloquear um ataque específico, mas até que você corrija a vulnerabilidade subjacente, ainda pode ser alvo de um ataque diferente.
Passo 5. Recompense o hacker ético
Mesmo que você não tenha um programa formal de recompensas, você deve apreciar e recompensar a ajuda do hacker. Afinal, o relatório deles pode ter te salvado de uma situação potencialmente prejudicial, especialmente se o bug pudesse ter sido explorado ativamente, causando uma violação de dados e perda de reputação.
O que fazer:
Decida internamente o que está disposto a pagar ao hacker pela ajuda (e formalize o processo - consulte o passo 7). Certifique-se de que quem aprova esses pagamentos esteja totalmente ciente das perdas e danos potenciais se um hacker malicioso tivesse encontrado e explorado a vulnerabilidade.
Se o hacker ajudar sua equipe com a remediação e reteste, esteja pronto para aumentar a recompensa.
O que não fazer:
Não tente evitar conceder uma recompensa. Seja honesto e transparente, evitando práticas enganosas, como dizer que o bug já foi relatado e uma recompensa foi paga. Confiança e respeito são fundamentais na comunidade de pesquisadores de segurança independentes.
Passo 6. Divulgue a vulnerabilidade
Depois que a vulnerabilidade for corrigida, é uma prática recomendada divulgar a questão e todas as informações relacionadas por pelo menos duas razões. Em primeiro lugar, sempre há o risco de que atores maliciosos já tenham explorado a vulnerabilidade silenciosamente, então você deseja ser o primeiro a divulgá-la (em vez de ver o nome de sua empresa em divulgações de terceiros anunciando que seus dados confidenciais foram roubados). E em segundo lugar, a publicação de um relatório completo é sempre muito positiva para a imagem de sua empresa na indústria de segurança - como um exemplo, veja o que a Cloudflare fez quando encontrou um grande problema.
O que fazer:
Preparar um relatório detalhado, incluindo informações sobre quem encontrou e relatou a vulnerabilidade, como ela foi confirmada e como foi corrigida. Inclua o máximo de detalhes técnicos possível com segurança.
Publicar o relatório em seu site e/ou redes sociais. Se necessário, comunique-se diretamente com todas as partes que possam ter sido afetadas pela vulnerabilidade.
O que não fazer:
Não trate a divulgação responsável de vulnerabilidades como algo que possa prejudicar sua empresa e deva ser evitado. Informações claras sobre como um problema foi introduzido, relatado e corrigido podem ser inestimáveis para outras organizações, e divulgá-las torna todos mais seguros.
Passo 7. Construa uma política de divulgação de vulnerabilidades
Após corrigir o problema imediato, aproveite a oportunidade para aprender com a experiência. Se esta foi a primeira vez que lidou com um relatório externo, é provável que tenha executado muitos dos passos acima ad hoc, então é uma boa ideia definir procedimentos para o futuro. A melhor maneira de fazê-lo é criar seu próprio programa de divulgação de vulnerabilidades e um programa de recompensa por bugs.
Embora muitas empresas ainda não tenham esses programas, gigantes da tecnologia como Microsoft e Google estão bem-preparados, então você pode querer seguir seus passos.
O que fazer:
Descreva o seu processo preferido de divulgação coordenada de vulnerabilidades (VDP). Decida como gostaria de ser informado sobre vulnerabilidades no futuro. Designe uma pessoa para receber relatórios por e-mail, telefone ou qualquer outro canal que você selecionar.
Crie um arquivo security.txt para o seu site com as informações relevantes e certifique-se de que suas informações de contato sejam fáceis de encontrar.
Decida sobre o escopo dos prêmios de caça a bugs que você está disposto a conceder. Forneça faixas de pagamento com base em parâmetros específicos, como criticidade de negócios e classe de vulnerabilidade. Você pode usar a funcionalidade de classificação automática de problemas nos produtos da Invicti como ponto de partida para decidir quais tipos de vulnerabilidades merecem quais prêmios para qual local e criticidade.
Publique informações sobre o seu processo de divulgação coordenada de vulnerabilidades (CVD) em seu site, juntamente com suas diretrizes de divulgação, métodos de teste aceitáveis e condições de caça a bugs. Certifique-se de que essas informações sejam fáceis de encontrar e fáceis de ler, mesmo para pessoas que não são falantes nativos de inglês.
Você também pode trabalhar com um parceiro terceirizado para ajudá-lo no processamento de relatórios de vulnerabilidades e na comunicação com hackers - HackerOne e Bugcrowd são duas plataformas populares. Tais plataformas externas automatizam muitas das etapas envolvidas na notificação de vulnerabilidades e no pagamento de recompensas, e também são consideradas um porto seguro pela comunidade, ajudando os hackers a evitar empresas antiéticas.
O que não fazer:
Não assuma que adotar uma política de divulgação de vulnerabilidades irá protegê-lo de problemas de segurança de aplicativos da web. Saber como responder a divulgações responsáveis é apenas uma pequena parte do seu programa de segurança de aplicativos. Ainda é necessário realizar testes de segurança regulares usando pelo menos um scanner automático de vulnerabilidades. Para encontrar e eliminar problemas do desenvolvimento à produção, é uma boa prática escanear regularmente aplicativos de produção em busca de vulnerabilidades, além de integrar testes de segurança diretamente ao seu ciclo de vida de desenvolvimento de software (SDLC).
Em um mundo cada vez mais conectado e dependente de tecnologia, a segurança cibernética é uma preocupação crescente. A divulgação não coordenada de vulnerabilidades pode expor organizações e indivíduos a riscos significativos de segurança. Por isso, seguir os 7 passos para evitar essa prática é fundamental para proteger seus sistemas e dados.
Ao implementar medidas preventivas, como estabelecer uma política de divulgação responsável, manter o software atualizado e trabalhar em colaboração com fornecedores de software e especialistas em segurança, é possível minimizar os riscos de vulnerabilidades e manter a segurança cibernética em dia.
Não se trata apenas de uma questão de evitar ameaças e prevenir ataques, mas também de proteger a privacidade e a confidencialidade de informações sensíveis. Ao seguir os 7 passos para evitar divulgação não coordenada de vulnerabilidades, você estará contribuindo para um ambiente mais seguro e confiável na internet.
