Coordinated vulnerability disclosure

Divulgação coordenada de vulnerabilidades (CVD)

Como comunicar, receber e coordenar vulnerabilidades de segurança, com exemplos de políticas.

A divulgação coordenada de vulnerabilidades (Coordinated vulnerability disclosure, CVD) é um termo de segurança informática. Descreve como as pessoas podem partilhar relatórios sobre problemas de segurança. Exemplos são relatórios de erros, riscos de intrusão, avisos de pirataria informática, fugas de dados, violações de sítios web, etc.

Traduções: العربية, Български, বাংলা, Čeština, Cymraeg, Dansk, Deutsch, Ελληνικά, English, Español, Eesti, Euskara, فارسی, Suomi, Français, Gaeilge, Gàidhlig, ગુજરાતી, Hausa, עברית, हिन्दी, Hrvatski, Magyar, Bahasa Indonesia, Íslenska, Italiano, 日本語, 한국어, Lietuvių, Latviešu, Nederlands, Polski, Português, Română, Русский, Slovenčina, Slovenščina, Svenska, Kiswahili, ไทย, Türkçe, Українська, اردو, Tiếng Việt, 中文

Conteúdo:

Políticas:

Introdução

Este documento explica a divulgação coordenada de vulnerabilidades de formas que podem ajudar as pessoas a trabalhar em conjunto.

Objetivos do documento:

  1. Ajudar as pessoas que descobrem problemas de segurança e querem comunicá-los.

  2. Ajudar os representantes das empresas a compreender as necessidades, os objetivos, as práticas e os casos especiais da divulgação responsável.

  3. Incluir exemplos de políticas de divulgação coordenada de vulnerabilidades na pasta do repositório.

Aceitamos pull requests, issues do GitHub ou mensagens de correio eletrónico para security@joelparkerhenderson.com.

O que é a divulgação coordenada de vulnerabilidades?

A divulgação coordenada de vulnerabilidades descreve três passos quando alguém descobre um problema de segurança (como um erro de software) e quer comunicá-lo ao produtor (como a empresa que fabrica o software).

Passos:

  1. O descobridor comunica o problema em privado e de boa-fé ao produtor.

  2. O produtor tenta proteger os utilizadores de boa-fé e procura resolver o problema.

  3. Passado um determinado período de tempo, o problema de segurança é tornado público.

Passo 1: Comunicar o problema

O passo 1 é para o descobridor: comunicar o problema em privado e de boa-fé.

  • Bom: O descobridor envia a informação relevante ao produtor, por exemplo por correio eletrónico para o endereço de segurança do produtor (normalmente "security@example.com") ou através de um formulário na página web do produtor (normalmente "https://www.example.com/security").

  • Mau: publicar o relatório num blogue público, ou alertar os meios de comunicação social, ou fazer ameaças, ou tentar vender o problema de segurança a piratas informáticos, etc.

  • Dica: o descobridor pode optar por ser anónimo; o produtor também pode optar por ser anónimo.

Se quiser, continue a acompanhar o problema.

  • Bom: abrir linhas de comunicação, ou fornecer informação de seguimento, ou monitorizar a situação.

  • Mau: esquecer-se do problema.

  • Dica: o descobridor pode optar por ajudar ou não, e também pode optar por manter a comunicação ou não, e também pode optar por alterar o acordo se as circunstâncias mudarem.

Se quiser, divulgue o problema a outros.

  • Bom: esperar o período de tempo especificado e depois tornar público, por exemplo publicando a informação relevante num sítio de notícias de segurança, ou contactando investigadores de segurança terceiros relevantes, ou anunciando o problema em qualquer sítio social público, etc.

  • Mau: não divulgar o problema a outros, a menos que sinta que isso causaria um risco superior ao proporcional para si ou para outros.

  • Dica: se as circunstâncias mudarem, por exemplo com a descoberta de um risco maior ou de uma exploração ativa em circulação (active exploit in the wild), o descobridor pode divulgar o problema a outros mais cedo.

Passo 2: Garantir os contactos

O passo 2 é para o produtor: garantir que os contactos são viáveis.

  • Bom: O produtor publica um endereço de correio eletrónico de contacto de segurança (por convenção "security@example.com") e, idealmente, uma chave segura de cifragem de correio eletrónico.

  • Bom: O produtor publica uma página web de contacto de segurança (por convenção "https://www.example.com/security") e, idealmente, torna a página fácil de encontrar, por exemplo através do rodapé do sítio web, do mapa do sítio e da pesquisa.

  • Mau: O produtor não fornece um endereço de correio eletrónico nem uma página web, ou não os torna fáceis de encontrar.

Garantir as capacidades dos funcionários.

  • Bom: O produtor forma os funcionários de apoio sobre o que fazer se receberem uma questão de segurança, por exemplo como responder com informações de contacto ou como reencaminhar a questão para a equipa interna certa.

  • Bom: O produtor verifica periodicamente que as capacidades dos funcionários estão a funcionar.

  • Mau: O produtor não forma ou não verifica.

Responder ao descobridor dentro do prazo.

  • Se o descobridor não especificar um prazo, utilize um dia útil, porque este é o padrão da indústria e a atual melhor prática do setor.

  • Se o descobridor fizer perguntas, responda-lhes. Isto é especialmente importante se o descobridor pedir autorização para testar. Garanta que todas as respostas são claras e diretas.

Responder ao descobridor através de um contacto de segurança autorizado e/ou de um processo de segurança autorizado.

  • Bom: uma resposta de um endereço de correio eletrónico específico de segurança, como "security@example.com".

  • Por exemplo, isto é mau: uma resposta de um endereço de correio eletrónico de uso geral, como "help@example.com", ou de alguém que não seja um profissional de segurança autorizado.

Informar o descobridor de que o problema é reconhecido como um relatório de segurança.

  • Bom: formulações específicas de segurança, como "A nossa equipa de segurança recebeu o seu relatório de divulgação responsável", ou "O nosso processo de segurança tem os seguintes passos seguintes", ou "A sua informação está agora no nosso sistema de seguimento de segurança com o número de identificação XYZ", etc.

  • Mau: formulações de uso geral, como "Agradecemos o seu negócio", ou "Levamos a segurança a sério", formulações de passa-culpas como "Enviámos o seu correio eletrónico para outro departamento", etc.

Passo 3: Trabalhar de boa-fé

O passo 3 é para o descobridor e o produtor em conjunto: trabalhar de boa-fé.

Compreenda que a divulgação coordenada de vulnerabilidades descreve um processo de boa-fé.

  • O objetivo n.º 1 é a boa-fé para ajudar os utilizadores a protegerem-se de riscos de segurança.

  • O objetivo n.º 2 é a boa-fé para resolver o problema de segurança.

  • O descobridor e/ou o produtor podem optar de boa-fé por envolver outras pessoas de segurança, por exemplo contactando outros investigadores de segurança relevantes para ajudar com o problema.

Compreenda que a divulgação coordenada de vulnerabilidades não cria qualquer obrigação.

  • O descobridor e/ou o produtor podem desistir a qualquer momento, por qualquer razão, com ou sem aviso. É cortês manter todas as pessoas relevantes informadas e atualizadas, mas isso nem sempre é possível, prático ou desejável.

  • A divulgação coordenada de vulnerabilidades não cria qualquer acordo jurídico. Se o descobridor e o produtor já tiverem um acordo jurídico, sugerimos que todos os envolvidos consultem os advogados adequados; não utilize este documento como aconselhamento jurídico.

Compreenda que a divulgação coordenada de vulnerabilidades visa utilizar uma boa comunicação e rejeitar ameaças.

  • A divulgação coordenada de vulnerabilidades é melhor quando todos os envolvidos compreendem que o objetivo n.º 1 é ajudar os utilizadores a protegerem-se de riscos de segurança e o objetivo n.º 2 é resolver o problema de segurança.

  • A divulgação coordenada de vulnerabilidades rejeita qualquer tipo de ameaça de retaliação, intimidação, suspensão, revogação, extorsão, encargo de acompanhamento ou culpabilização da vítima.

Compreenda que a divulgação coordenada de vulnerabilidades pode significar coisas diferentes para pessoas diferentes.

  • O descobridor e o produtor podem ter entendimentos diferentes da divulgação coordenada de vulnerabilidades. Estes entendimentos podem não coincidir. A boa-fé inclui todos os envolvidos compreenderem isto.

  • Alguns produtores publicam políticas de divulgação coordenada de vulnerabilidades. Estas podem ser uma orientação útil. Se um descobridor optar por utilizar outro tipo de divulgação coordenada de vulnerabilidades, ou tiver um entendimento diferente de divulgação responsável, isso é absolutamente aceitável.

Compreenda que, normalmente, o descobridor está a fazer um favor ao editor.

  • Normalmente, o descobridor não precisa da autorização de ninguém para publicar vulnerabilidades.

  • Normalmente, a informação do descobridor ajuda o editor.

Verificar o sucesso

Depois de o problema ser resolvido, o produtor deve verificar o sucesso.

  • Todas as pessoas e processos trataram a divulgação com sucesso? Se sim, ótimo. Se não, considere fazer uma investigação posterior, como a análise de causa raiz (RCA), relatórios post-mortem, diagramas de Ishikawa ou análise causal baseada na teoria de sistemas (CAST).

  • As questões pendentes foram triadas e estão a ser acompanhadas?

  • O produtor e o descobridor compreendem ambos o que fazer em quaisquer passos seguintes? Isto é especialmente importante acertar caso possa haver divulgações coordenadas de vulnerabilidades subsequentes.

Orientações

As orientações para a divulgação coordenada de vulnerabilidades podem vir de muitas áreas, como peritos em ética, defensores jurídicos, as expectativas razoáveis do público em geral, etc.

Se procura orientação, pode interessar-se por estas três áreas, todas descritas abaixo.

  • Bom Samaritano

  • Dever de socorro

  • Dever de diligência

Bom Samaritano

Wikipedia: Lei do Bom Samaritano

As leis do Bom Samaritano (Good Samaritan laws) oferecem proteção jurídica às pessoas que prestam assistência razoável a quem está, ou a quem acreditam estar, ferido, doente, em perigo ou de outra forma incapacitado. A proteção destina-se a reduzir a hesitação dos transeuntes em ajudar, por receio de serem processados ou acusados.

Dever de socorro

Wikipedia: Dever de socorro

Um dever de socorro é um conceito que descreve uma circunstância em que uma parte pode ser responsabilizada por não ter socorrido outra parte em perigo. Um dever de socorro pode ter áreas morais e/ou jurídicas.

Dever de diligência

Wikipedia: Dever de diligência

Um dever de diligência é a obrigação de respeitar um padrão de cuidado razoável ao praticar quaisquer atos que possam prever-se como prejudiciais para outros. Um dever de diligência pode ter áreas morais e/ou jurídicas. Alguns aspetos a considerar são: a previsibilidade do dano ou lesão, a possível magnitude do dano ou lesão potencial, a importância ou o valor social da atividade em que o réu estava envolvido, a utilidade da conduta para o réu, a viabilidade de uma conduta alternativa, os custos e encargos associados à conduta alternativa, a utilidade relativa da conduta alternativa e a segurança relativa da conduta alternativa.

Casos especiais

As nossas equipas de segurança viram uma grande variedade de casos especiais.

Descrevemo-los aqui para ajudar as pessoas a compreender onde há uma grande variedade de opiniões sobre o que pode estar bem e o que pode não estar bem. Recomendamos que todos os envolvidos comuniquem de boa-fé sobre estes casos.

Aceder a informações de outros utilizadores

Exemplo: descobre que um URL tem o seu identificador de utilizador, revela um erro, e acredita que pode editar o URL para mudar o seu identificador de utilizador para outro identificador de utilizador.

  • Está bem o descobridor fazer isto, por exemplo com o único objetivo de descobrir se afeta também outros utilizadores?

  • É mais importante compreender rapidamente a extensão do risco para todos os utilizadores do que proteger alguns utilizadores cuja informação possa já estar visível para piratas informáticos?

  • Está bem o descobridor fazer isto com tantos utilizadores quantos quiser?

  • Está bem o descobridor tentar contactar os utilizadores para os informar de que estão afetados? Está bem oferecer sugestões de mitigação?

Negação de serviço

Exemplo: descobre um erro que suspende acidentalmente a sua conta, como acionar um bloqueio de palavra-passe.

  • Isto é considerado um ataque de negação de serviço?

Correio eletrónico não solicitado

Exemplo: tenta comunicar um problema de segurança a pessoas da empresa que considera relevantes, e que descobre pesquisando no LinkedIn, Facebook, etc., ou usando convenções de nomes como "webmaster@example.com" ou "security@example.com".

  • Isto está bem?

  • Isto é considerado correio eletrónico não solicitado (unsolicited email)?

  • Isto é considerado correio eletrónico não autorizado (unauthorized email)?

Grupos excluídos

Exemplo: está num grupo excluído, como ser menor, ou estar numa lista de sanções, ou estar num país que consta de uma lista de sanções.

  • Está bem fazer um relatório?

  • Está bem comunicar de forma anónima?

  • Está bem alterar deliberadamente informação potencialmente identificadora, por exemplo para escapar ao grupo excluído e com o objetivo de ajudar a divulgação a chegar às pessoas certas?

Terceiros

Exemplo: descobre que o software de uma empresa tem um erro que envolve um terceiro, como uma integração com outro software ou outro sítio web.

  • Está bem comunicar toda a informação que encontra a ambas as partes?

  • É necessário fazer duas divulgações responsáveis diferentes, por exemplo um relatório a uma empresa e um relatório diferente à empresa terceira, com o objetivo de limitar a informação enviada a cada empresa?

  • Está bem o descobridor pôr as empresas em contacto uma com a outra?

Software perturbador

Exemplo: tem competência suficiente para ser capaz de escrever um vírus que acredita ser provável que ajude os utilizadores a protegerem-se do risco de segurança, ou a identificar se estão em risco, ou a corrigir o risco de segurança.

  • Está bem?

  • Está bem o descobridor indicar aos utilizadores software como este, e/ou guias ou tutoriais que descrevem como criar este tipo de software?

Divulgação coordenada de vulnerabilidades vs. divulgação responsável

A divulgação coordenada de vulnerabilidades é o termo preferido.

  • O aspeto mais importante é a coordenação entre descobridor e produtor.

A divulgação responsável (responsible disclosure) é um termo em desuso.

  • As pessoas têm perspetivas diferentes sobre o que significa ser responsável. Por exemplo, algumas pessoas defendem que é responsável o descobridor notificar o público imediatamente, independentemente de qualquer interação com o produtor, e irresponsável fazer divulgação coordenada de vulnerabilidades porque esconde informação do público.

Acompanhamento