NCSC.nl

1. Introdução

A sociedade está cada vez mais digitalizada. Atualmente, quase todos os processos envolvem em algum momento a utilização de computadores, desde telemóveis a software especializado. Embora esta evolução crie muitas novas oportunidades, as vulnerabilidades nos sistemas de TI podem ter um impacto importante. Por conseguinte, o conhecimento sobre estas vulnerabilidades deve ser tratado de forma eficaz.

Um conjunto de organizações começou a publicar políticas sobre como comunicar vulnerabilidades no início de 2013. Após consulta a estas partes, o Centro Nacional de Cibersegurança (National Cyber Security Centre, NCSC) resumiu a evolução sob a forma de ‘Diretrizes para alcançar uma prática de Divulgação Responsável’ (em neerlandês: ‘Leidraad om te komen tot een praktijk van Responsible Disclosure’; as ‘Diretrizes’). As empresas indicam através desta política que estão abertas a receber relatórios externos de vulnerabilidades, descrevem as suas condições prévias e fazem promessas. Este processo criou clareza e um ambiente algo seguro para as partes que comunicam investigarem e comunicarem vulnerabilidades sem cometerem diretamente uma infração penal. Na reunião de alto nível da UE sobre cibersegurança em 2016, 29 organizações reafirmaram a importância de uma política para lidar com vulnerabilidades, assinando o Manifesto de Divulgação Coordenada de Vulnerabilidades (Coordinated Vulnerability Disclosure Manifesto)1, iniciado pela CIO Platform Netherlands e pelo Rabobank em cooperação com o NCSC.

A Divulgação Coordenada de Vulnerabilidades (CVD) revelou-se de grande importância para partes públicas e privadas. Estas dependem fortemente do funcionamento sem perturbações dos sistemas de informação na prática diária. Os relatórios de vulnerabilidades nos seus sistemas ajudaram a melhorar a segurança e a continuidade dos sistemas nos últimos anos, por um lado corrigindo vulnerabilidades e, por outro, contribuindo para a sensibilização geral das empresas neerlandesas para a segurança de TI.

Nos últimos anos, tornou-se claro que as partes que comunicam estão preparadas para trabalhar dentro das condições da política de CVD elaborada pelas organizações. Os relatórios são feitos, direta ou indiretamente, às organizações pelas partes que comunicam. A prática de divulgação responsável mostrou que partes que comunicam bem-intencionadas e organizações vulneráveis conseguiram cooperar e, assim, dar o passo seguinte no aumento da segurança dos sistemas de rede e de informação.

Para esta revisão, falámos mais uma vez com um grupo amplo e diversificado de partes que comunicam, partes privadas e públicas, bem como com o Ministério Público e a Polícia Nacional. Estas conversas confirmaram a prática atual e levaram a acrescentos e melhorias. O novo ponto de atenção mais importante é a comunicação entre o autor do relatório da vulnerabilidade e a organização, bem como com outras partes depois de uma vulnerabilidade ter sido corrigida.

Os capítulos seguintes discutem a definição de CVD, os elementos constituintes de uma política de CVD e o processo de comunicação.

Nota: As Diretrizes anteriores utilizavam o termo ‘divulgação responsável’ (responsible disclosure), que era então o termo comum para esta prática. Entretanto, tornou-se claro que este termo coloca demasiada ênfase na responsabilidade da parte que comunica, quando o princípio básico é que a parte que comunica e a organização potencialmente vulnerável devem ser parceiros iguais no diálogo. Este sentimento é melhor captado pelo termo atualmente usado ‘Divulgação Coordenada de Vulnerabilidades’ (Coordinated Vulnerability Disclosure, CVD), que é também o nome utilizado nas normas ISO 29147 e 30111 sobre este processo.

2. Vulnerabilidade coordenada

Foram utilizados vários métodos nos últimos 30 anos para sensibilizar para as vulnerabilidades nos sistemas de TI. Exemplos incluem:

• ‘Divulgação Total’ (Full Disclosure), tornar uma vulnerabilidade totalmente pública;

• ‘Não divulgação’ (Non-disclosure), vender ou utilizar uma vulnerabilidade por si próprio;

• ‘Divulgação Coordenada de Vulnerabilidades’ (CVD), a divulgação coordenada de uma vulnerabilidade.

A última prática é expressamente preferida.

A comunidade de TI tem mostrado grande vontade de partilhar conhecimentos e experiência. Procurar cooperação com esta comunidade pode, por isso, ajudar a melhorar a segurança global dos sistemas.

O objetivo da divulgação coordenada de vulnerabilidades

O objetivo da CVD é contribuir para a segurança dos sistemas de TI através da partilha de conhecimentos sobre vulnerabilidades. Na CVD, o conhecimento é partilhado com uma ou mais organizações potencialmente vulneráveis para se chegar a uma solução conjunta para a vulnerabilidade encontrada, em colaboração com a parte que comunica. É importante que as organizações afetadas tenham tempo suficiente para corrigir quaisquer vulnerabilidades ou proteger os sistemas, a fim de limitar ou evitar perdas ou danos tanto quanto possível. A pedra angular do processo é a divulgação do conhecimento sobre as vulnerabilidades após a correção.

É essencial na CVD que todas as partes cumpram os acordos sobre como comunicar uma vulnerabilidade e como lidar com ela. Ajuda se uma organização publicar antecipadamente as condições prévias, como quais os sistemas que estão no âmbito e que tipo de investigação pode ser realizada. Um princípio importante para estas condições prévias é que, em princípio, a organização não denunciará a parte que comunica nem tomará outras medidas legais se a investigação e a comunicação forem realizadas dentro das condições estabelecidas. Estas Diretrizes fornecem às organizações orientações para elaborar a sua própria política que concretize os princípios da CVD.

Como o nome indica, é central na CVD que a organização e a parte que comunica se coordenem entre si. A este respeito, deve haver o menor número possível de elos entre a pessoa que comunica a vulnerabilidade e a pessoa dentro da organização que é responsável por resolver o problema.

Pode ser importante informar várias partes ao mesmo tempo se uma vulnerabilidade afetar muitos sistemas. Nesse caso, o NCSC ou outras partes da comunidade de segurança podem apoiar o processo de CVD a partir de um papel de coordenação.

3. Áreas de responsabilidade

O objetivo de prosseguir uma política de CVD é que as partes que comunicam e a organização trabalhem em conjunto para reduzir as vulnerabilidades nos sistemas de TI. A aplicação desta política deve ser vista como um complemento das medidas existentes em matéria de segurança da informação. Os vários intervenientes têm cada um o seu próprio papel e responsabilidades. Estes são explicados com mais pormenor abaixo.

A organização que detém/gere um sistema

A organização que detém/gere ou fornece um sistema é a principal responsável pela segurança desse sistema. Por outras palavras, a organização é também responsável por dar seguimento a um relatório de vulnerabilidade.

A organização pode optar por elaborar a sua própria política de CVD utilizando estas Diretrizes e por comunicar essa política às potenciais partes que comunicam. Ao publicar uma política de CVD, as organizações mostram a sua disponibilidade para receber informação sobre vulnerabilidades.

Uma parte que estabelece uma política de CVD pode comprometer-se com o princípio de que não apresentará queixa à polícia se as regras aplicáveis à política forem respeitadas.

Depois de uma parte que comunica ter comunicado uma vulnerabilidade, a responsabilidade cabe à organização. É importante perceber que a parte que comunica é frequentemente alguém de fora da organização. Esta parte não tem uma visão direta dos processos internos que podem ser desencadeados depois de uma vulnerabilidade ser comunicada. Como resultado, as partes que comunicam apreciarão ser informadas dos desenvolvimentos na resolução da vulnerabilidade. Esta comunicação contínua é também importante para criar as expectativas certas quanto ao seguimento e à oportunidade da solução.

A parte que comunica uma vulnerabilidade

De uma forma ou de outra, a parte que comunica conseguiu identificar uma vulnerabilidade e quer contribuir para a segurança dos sistemas de TI fazendo com que esta vulnerabilidade seja corrigida e possivelmente tornada pública numa fase posterior. A parte que comunica pode ter descoberto algo através de observação passiva ou testando ativamente o sistema de TI. Naturalmente, esta parte é responsável pelas suas próprias ações e pela forma como descobriu a vulnerabilidade. É responsabilidade da própria parte que comunica estar ciente das condições estabelecidas por uma organização na sua política de CVD. A maioria dos governos e empresas publicou as suas políticas de CVD nos seus sítios web.

Encontrar vulnerabilidades pode, no entanto, envolver a violação da lei. No contexto da CVD, a organização e a parte que comunica podem acordar que não apresentarão queixa por quaisquer atos criminosos. A este respeito, a política de CVD publicada pela organização é o princípio orientador. As partes podem também acordar que não será tomada qualquer medida civil.

Se houver suspeita de que a lei foi violada pela parte que comunica, uma política de CVD pode, antes de mais, ajudar a evitar que o autor do relatório seja denunciado às autoridades. Este procedimento depende inteiramente das condições prévias da política que uma organização exige que uma parte que comunica cumpra e de este cumprimento ter sido alcançado, possivelmente com uma promessa correspondente de não apresentar queixa-crime desde que a parte opere dentro das condições da política. Se for feita uma participação à polícia, a existência e o cumprimento de uma política de CVD são uma circunstância relevante nos Países Baixos, que o Procurador do Ministério Público terá em conta ao decidir se inicia uma investigação criminal e/ou procede judicialmente. Em princípio, a polícia e o Ministério Público (OM) não iniciarão uma investigação criminal se a parte que comunica tiver claramente cumprido as regras da política de CVD da organização em causa. No entanto, o Ministério Público e a polícia podem investigar mais o caso se houver indícios de que a parte que comunica foi, consciente ou inconscientemente, longe demais nas suas ações e/ou não cumpriu a política de CVD. Com base nesta investigação, o Ministério Público pode decidir se procede judicialmente.

O Ministério Público publicou uma carta de orientação em que trata mais especificamente de aspetos que são importantes para chegar a uma decisão de investigar e/ou de proceder judicialmente. Por exemplo, se as ações da parte que comunica serviram um interesse público importante, se a parte agiu de forma desproporcionada e se a parte poderia talvez ter agido de outra forma, menos drástica. A carta de orientação relevante desenvolve estes aspetos.2 A jurisprudência relevante desde 20133 mostra que estes aspetos também são tidos em conta em tribunal se uma organização não tiver uma política de CVD.

4. Elementos constituintes do processo de Divulgação Coordenada de Vulnerabilidades

Seguem-se elementos constituintes para dar forma ao processo de CVD para a organização, o autor do relatório e o NCSC.

A organização

A promoção da CVD começa numa organização que detém sistemas de TI ou que fornece um produto/sistema de TI. Afinal, esta organização é a principal responsável pela segurança da informação destes sistemas de TI. Para trabalhar eficazmente com várias partes na resolução de vulnerabilidades, uma organização pode decidir elaborar e publicar uma política de CVD. Elaborar a sua própria política de CVD permite à organização demonstrar como lida com os relatórios de vulnerabilidades. Desta forma, uma organização pode também dar forma à maneira como deseja receber notificações. Tal processo pode ser organizado da seguinte forma:

• A organização estabelece e publica uma política de CVD.

• Nesta política, a organização fornece regras claras para a investigação que as partes que comunicam podem realizar, como quais as técnicas permitidas e quais os sistemas dentro ou fora do âmbito.

• A organização facilita a uma parte que comunica a apresentação de um relatório. Uma opção é a utilização de um método de comunicação normalizado; por exemplo, um endereço de correio eletrónico específico ou um formulário em linha. Além disso, a organização pode decidir se aceita relatórios anónimos.

• A organização reserva capacidade interna e estabelece um processo para responder adequadamente aos relatórios. É aconselhável estabelecer um processo com o qual quaisquer vulnerabilidades encontradas possam ser adequadamente corrigidas. A este respeito, a origem do relatório é irrelevante. A vulnerabilidade pode também ter sido identificada por um funcionário interno ou durante um teste, por exemplo.

• A experiência prática mostra que haverá maior interesse em comunicar vulnerabilidades à organização após a publicação inicial de uma política de CVD. A organização deve ter isto em conta no planeamento de capacidade (adicional).

• Quando a organização recebe o relatório de vulnerabilidade, assegura que o relatório chega o mais depressa possível ao departamento mais adequado para o avaliar e tratar.

• A organização envia uma confirmação de receção do relatório à parte que comunica, de preferência assinada digitalmente para enfatizar a prioridade.

• Posteriormente, a organização entrará em consulta com a parte que comunica para determinar o período dentro do qual qualquer publicação terá lugar. Este período dependerá em grande medida da natureza da vulnerabilidade e do tipo de sistema.

• Como orientação, é frequentemente utilizado um período de aproximadamente 60 dias para vulnerabilidades de software. Corrigir vulnerabilidades em hardware é mais difícil de conseguir; pode utilizar-se uma orientação de 6 meses.

• Pode ser desejável prolongar ou encurtar este período por acordo mútuo, consoante o número de sistemas de TI que dependem do sistema para o qual a vulnerabilidade foi comunicada ou se a vulnerabilidade é mais fácil ou mais difícil de resolver.

• Uma vulnerabilidade pode revelar-se difícil ou impossível de resolver, ou pode haver custos elevados envolvidos na sua resolução. Nesses casos, a organização pode acordar em considerar a vulnerabilidade um risco aceite e não a corrigir, eventualmente em consulta com a parte que comunica.

• A organização manterá a parte que comunica informada sobre o desenvolvimento do processo.

• Além disso, a organização pode oferecer que a parte que comunica seja reconhecida publicamente por publicar a vulnerabilidade. É também possível optar por uma divulgação conjunta ao exterior.

• É preferível recompensar a parte que comunica por comunicar vulnerabilidades em sistemas se a parte tiver cumprido as regras da política de CVD. O montante da recompensa pode depender da qualidade do relatório. Recompensar a parte que comunica pode criar uma melhor relação entre essa parte e a organização, bem como aumentar a disponibilidade das pessoas para fazerem novos relatórios de acordo com a política de CVD.

• Em consulta com a parte que comunica, a organização pode acordar em informar a comunidade de TI mais alargada sobre a vulnerabilidade, se for plausível que a vulnerabilidade também esteja presente noutros locais.

• Na sua política de CVD, a organização pode comprometer-se com o princípio de que não apresentará queixa à polícia se a parte que comunica tiver cumprido as regras descritas na política.

A parte que comunica

A parte que comunica é a chave para um processo de CVD bem-sucedido. De uma forma ou de outra, esta parte conseguiu identificar uma vulnerabilidade e quer contribuir para a segurança dos sistemas de TI fazendo com que esta vulnerabilidade seja corrigida por uma organização e tornada pública. Ao fazê-lo, as partes que comunicam reconhecem que podem dar um contributo importante para a sociedade ao revelar vulnerabilidades de forma coordenada. Para alcançar um processo de CVD bem-sucedido, os seguintes elementos são importantes para a parte que comunica:

• A parte que comunica é responsável pelas suas próprias ações e deve respeitar os princípios da proporcionalidade e da subsidiariedade ao investigar e comunicar vulnerabilidades. Por outras palavras, a parte que comunica não deve fazer mais do que o necessário para demonstrar a vulnerabilidade e deve sempre comunicar primeiro a vulnerabilidade ao proprietário do sistema/informação.

• A parte que comunica deve comunicar o problema o mais depressa possível para evitar que partes mal-intencionadas descubram a vulnerabilidade e tirem partido dela.

• A parte que comunica deve fazer a comunicação à organização de forma confidencial para evitar que outros tenham acesso a esta informação.

• A parte que comunica não pode fazer depender a apresentação de um relatório ou o fornecimento adicional de informação da recompensa. A iniciativa de conceder uma recompensa em caso de relatório cabe à organização recetora, que pode definir condições prévias na sua política publicada.

• A parte que comunica e a organização estabelecem acordos claros sobre a divulgação da vulnerabilidade. Se mais do que uma organização estiver envolvida, o princípio básico é que as vulnerabilidades só podem ser publicadas se todas as organizações concordarem com esse facto. É aconselhável estabelecer estes acordos numa fase precoce.

• A parte que comunica e a organização envolvida podem estabelecer acordos sobre a informação da comunidade de TI mais alargada. Por exemplo, esta situação pode aplicar-se a uma vulnerabilidade (já conhecida ou não) que se sabe estar presente em mais do que um local. O Centro Nacional de Cibersegurança (NCSC) pode ser envolvido neste processo para apoiar os grupos-alvo da administração central e das infraestruturas críticas ou para informar várias partes no caso de uma vulnerabilidade que afete muitos sistemas.

O NCSC

O processo de CVD é principalmente uma questão para organizações e partes que comunicam. No entanto, o NCSC incentivará a utilização de um processo de CVD. Em consulta com a parte que comunica e a organização, o NCSC pode também ser envolvido na partilha de informação sobre a vulnerabilidade com a sua comunidade de destino (constituency), a fim de limitar outros riscos de segurança decorrentes da vulnerabilidade.

Se a comunicação da vulnerabilidade não correr como a parte que comunica espera, ou se preferir não comunicar a vulnerabilidade diretamente à organização, pode contactar o NCSC.4 Neste caso, o NCSC pode atuar como intermediário sempre que necessário.

O proprietário do sistema de TI é sempre responsável pela segurança do sistema. O NCSC não pode forçar o proprietário do sistema a corrigir uma vulnerabilidade, nem pode garantir que o proprietário não tomará medidas legais contra a parte que comunica. Como resultado, a parte que comunica deve ter em conta os elementos constituintes acima referidos para organizações e partes que comunicam ao procurar e comunicar uma vulnerabilidade. Uma parte que comunica pode esperar que o NCSC faça tudo o que puder para que a vulnerabilidade seja corrigida e trate o relatório de forma confidencial. O NCSC não partilha quaisquer dados pessoais, a menos que seja legalmente obrigado a fazê-lo.

Se possível, o NCSC utilizará a informação obtida sobre vulnerabilidades, em consulta com as organizações e as partes que comunicam, para partilhar mais o conhecimento com a comunidade de TI. Por exemplo, pode fazê-lo publicando parte da informação, escrevendo ou atualizando uma ficha informativa (fact sheet) ou um livro branco (white paper), ou informando organizações específicas.

• Consoante a organização em causa e a natureza da vulnerabilidade estabelecida, o NCSC esforçar-se-á por levar a vulnerabilidade à atenção da organização em causa. No entanto, o proprietário do sistema de TI em questão continua a ser responsável pelo sistema.

• Sempre que possível e necessário, o NCSC fornecerá à organização em causa aconselhamento sobre como corrigir a vulnerabilidade.

• O NCSC tratará os relatórios de forma confidencial e não partilhará os dados pessoais das partes que comunicam ou da organização recetora sem consentimento, a menos que decorra de uma obrigação legal.

• Sempre que possível, o NCSC manterá a parte que comunica informada sobre os desenvolvimentos no contacto com a organização e na correção da vulnerabilidade.

• Nos casos em que um relatório é feito ao NCSC, o NCSC tentará pôr em contacto a parte que comunica ou potencial parte que comunica e a organização.

Se uma parte que comunica encontrou, por exemplo, uma vulnerabilidade num produto de software ou uma vulnerabilidade que afeta muitos sistemas diferentes, pode pedir ao NCSC que coordene a correção e a divulgação da vulnerabilidade.

Em conjunto com a parte que comunica, parceiros, programadores e/ou programadores de software e outras equipas de segurança, o NCSC ajudará a analisar, corrigir ou fazer corrigir, coordenar e divulgar a vulnerabilidade de forma controlada. Todo este processo decorre em estreita consulta com a parte que comunica que encontrou a vulnerabilidade.

Uma política de CVD tenta encontrar um equilíbrio entre a importância de divulgar as vulnerabilidades o mais depressa possível, para que possam ser tomadas medidas, e a importância de os programadores, bem como os fornecedores, terem tempo suficiente para corrigir a vulnerabilidade. Para este processo, o NCSC utiliza um prazo normal de 60 dias entre o relatório e a divulgação pública. No entanto, pode haver circunstâncias em que se possa decidir prolongar ou encurtar este período.

O NCSC só partilhará informação sobre a vulnerabilidade com terceiros após consulta com a parte que comunica. É essencial neste contexto que o NCSC coopere e, por conseguinte, partilhe informação sobre a vulnerabilidade com as partes interessadas, de modo a divulgar uma vulnerabilidade de forma coordenada. O NCSC assegurará, ao fazê-lo, que as partes certas possam trabalhar na correção da vulnerabilidade, ajudará a limitar quaisquer perdas ou danos e ajudará a chamar a atenção para a vulnerabilidade encontrada.

5. Comunicação e o processo de divulgação

Cinco anos de prática mostraram que a comunicação clara é a pedra angular de um processo de CVD bem-sucedido. Há pontos de atenção antes, durante e depois do processo de CVD.

Comunicação sobre o processo de divulgação

Publicar uma política de CVD é um primeiro passo na comunicação sobre o processo. Ao publicar publicamente uma política, as partes que comunicam são convidadas a notificar a organização de quaisquer vulnerabilidades encontradas.

Por um lado, a organização pode estabelecer condições para a investigação que é feita para descobrir vulnerabilidades e para a forma como o contacto é procurado. Por outro lado, a organização pode comprometer-se com o princípio de que não apresentará queixa à polícia se as regras da política forem respeitadas. Esta abordagem protege a posição da parte que comunica.

Uma política de CVD pode ser alterada ou atualizada numa data posterior. É importante ser claro quanto às alterações a este respeito. As partes que comunicam têm interesse em saber o que foi alterado e quando. Por exemplo, as alterações podem ser clarificadas incluindo uma data de publicação no início da política de CVD, descrevendo um resumo das alterações na política de CVD ou mantendo um arquivo com versões antigas da política de CVD.

A política de CVD pode fornecer orientações sobre como comunicar durante o processo, por exemplo indicando atualizações regulares por correio eletrónico ou através de um portal web. Além disso, a política de CVD pode descrever como um autor de relatório pode ser reconhecido mencionando-o numa atualização, admitindo-o num quadro de honra (hall of fame) ou através de qualquer outra forma de recompensa.

Comunicação durante o processo de divulgação

Uma parte que comunica inicia um processo de CVD enviando uma mensagem à organização. Nesta mensagem, a parte que comunica faz uma descrição clara da vulnerabilidade descoberta. Elementos importantes são o endereço IP ou o URL do sistema afetado e os passos necessários para reproduzir a vulnerabilidade.

É importante que a organização comunique claramente com a parte que comunica, para que as expectativas sobre o processo sejam claras.

Pode já fazê-lo enviando uma confirmação de receção (automatizada ou não) que contenha uma indicação do prazo em que será enviada uma resposta substantiva inicial ou posterior.

Também é possível deixar este período em aberto e dar uma indicação inicial do prazo depois de avaliar o conteúdo do relatório. É aconselhável ser claro o mais depressa possível sobre o período em que uma solução pode ser alcançada. Desta forma, o autor do relatório sabe quando se pode esperar um resultado.

Pode ser possível, em alguns casos, que uma data de publicação já seja clara para a parte que comunica; por exemplo, por causa de uma apresentação numa conferência ou porque a parte que comunica fixou o seu próprio prazo. Neste caso, é ainda importante que a parte que comunica transmita claramente este calendário, o indique o mais cedo possível e seja clara quanto à possibilidade/impossibilidade de adiar esta data.

Uma parte que comunica é frequentemente alguém de fora da organização, que não tem qualquer conhecimento dos processos internos que podem ser desencadeados por um relatório. As organizações podem manter a parte que comunica informada sobre a evolução do processo através de atualizações regulares. Esta abordagem torna claro para uma parte que comunica que se está a trabalhar numa solução. Sempre que necessário, uma organização pode pedir esclarecimentos ou testar uma solução durante o processo.

Se uma organização não conseguir cumprir o prazo de resolução inicial, pode discutir-se com o autor do relatório o seu adiamento. A comunicação regular pode tornar esta situação clara para o autor do relatório numa fase anterior.

A principal intenção da CVD é mitigar a vulnerabilidade, mas a ‘divulgação total’ da vulnerabilidade é sempre uma opção para uma parte que comunica se esta sentir que o processo demorará demasiado tempo. Esta medida é o proverbial ‘grande pau’ à disposição da parte que comunica. Naturalmente, esta situação deve ser evitada tanto quanto possível.

Comunicação após o processo de divulgação

Existem muitas razões possíveis pelas quais uma parte que comunica pode procurar vulnerabilidades e depois comunicá-las às organizações através do processo de CVD. Para um grande número de partes que comunicam, um incentivo importante é o reconhecimento (público).

As partes que comunicam recebem reconhecimento público através de um agradecimento numa atualização ou da entrada num quadro de honra. No entanto, a necessidade de reconhecimento público não se aplica a todas as partes que comunicam; algumas, de facto, não querem ser conhecidas do público. Em caso de comunicação por parte da organização, é por isso aconselhável obter o consentimento da parte que comunica para a nomear.

Além disso, as partes que comunicam podem também decidir comunicar sobre um relatório após a conclusão do processo de CVD. Por exemplo, a parte que comunica pode descrever o processo de descoberta ou alertar outros para a vulnerabilidade. Um autor de relatório pode decidir submeter a publicação a uma organização para fins informativos. Como o processo de CVD está, em princípio, concluído após a eliminação da vulnerabilidade, a parte que comunica fica depois livre de comunicar sobre o assunto, a menos que sejam feitos acordos adicionais na política ou durante o processo.

Lista

Comunicação sobre o processo de divulgação

• Publicação da política de CVD no sítio web

• Ser claro quanto às restrições (ver capítulo 6 para diferentes abordagens)

• Restrições nos métodos de investigação

• Orientações sobre a comunicação

• Orientações sobre possíveis recompensas: quadro de honra, recompensa financeira, t-shirt, etc.

• Ser claro quanto a quaisquer atualizações da política de CVD, incluindo a data das alterações

Comunicação durante o processo de divulgação

• O autor do relatório contacta a organização sobre uma vulnerabilidade descoberta.

• A organização gere expectativas, como o tempo de resposta para uma primeira resposta técnica

• A organização e o autor do relatório dão-se clareza mútua sobre o período de resolução esperado

• A organização fornece com frequência uma atualização (do processo)

• Sempre que necessário, o autor do relatório e a organização discutem o contacto com outras organizações relevantes

Comunicação após o processo de divulgação

• Discutir o reconhecimento (público) e a recompensa do autor do relatório

• Combinar como a informação sobre a vulnerabilidade será publicada, como a fase de investigação ou a informação a outras organizações

6. Exemplos de política de Divulgação Coordenada de Vulnerabilidades

Existem muitas formas diferentes de textos de política sobre Divulgação Coordenada de Vulnerabilidades. Como a política de CVD publicada funciona como um sinal de orientação para potenciais partes que comunicam, certifique-se de que a forma desta política está em linha com a política e a estratégia da organização.

Os seguintes elementos são importantes numa política de CVD:

• método de contacto para comunicação segura;

• condições prévias para as partes que comunicam;

• expectativas claras para o tratamento de um relatório;

• método de recompensa de um relatório;

• número de versão e data da última revisão.

Seguem-se três exemplos: Muitas organizações nos Países Baixos inspiraram-se no exemplo básico do ResponsibleDisclosure.nl. Outras organizações incluem condições prévias adicionais, veja-se a política da Fox IT. Outras organizações ainda aplicam um formato mais livre para se alinharem com o seu público-alvo, veja-se a política da Bits of Freedom.

Na Acme Corporation, consideramos a segurança dos nossos sistemas uma prioridade máxima. Mas, por muito esforço que dediquemos à segurança dos sistemas, ainda pode haver vulnerabilidades presentes.

Se descobrir uma vulnerabilidade, gostaríamos de saber para podermos tomar medidas para a resolver o mais depressa possível.

Gostaríamos de lhe pedir que nos ajude a proteger melhor os nossos clientes e os nossos sistemas.

Faça o seguinte:

• Envie as suas descobertas por correio eletrónico para cert@example.com. Cifre as suas descobertas com a nossa chave PGP para evitar que esta informação crítica caia em mãos erradas,

• Não tire partido da vulnerabilidade ou do problema que descobriu, por exemplo descarregando mais dados do que o necessário para demonstrar a vulnerabilidade ou apagando ou modificando dados de outras pessoas,

• Não revele o problema a outros até que esteja resolvido,

• Não use ataques à segurança física, engenharia social, negação de serviço distribuída, spam ou aplicações de terceiros, e

• Forneça informação suficiente para reproduzir o problema, para que possamos resolvê-lo o mais depressa possível. Normalmente, o endereço IP ou o URL do sistema afetado e uma descrição da vulnerabilidade serão suficientes, mas vulnerabilidades complexas podem exigir uma explicação adicional.

O que prometemos:

• Responderemos ao seu relatório no prazo de 3 dias úteis com a nossa avaliação do relatório e uma data prevista de resolução,

• Se seguiu as instruções acima, não tomaremos qualquer medida legal contra si em relação ao relatório,

• Trataremos o seu relatório com estrita confidencialidade e não transmitiremos os seus dados pessoais a terceiros sem a sua permissão,

• Mantê-lo-emos informado do progresso na resolução do problema,

• Na informação pública relativa ao problema comunicado, indicaremos o seu nome como descobridor do problema (a menos que deseje o contrário), e

• Como prova da nossa gratidão pela sua ajuda, oferecemos uma recompensa por cada relatório de um problema de segurança que ainda não nos fosse conhecido. O valor da recompensa será determinado com base na gravidade da fuga e na qualidade do relatório. A recompensa mínima será um cartão-presente de 50 €.

Esforçamo-nos por resolver todos os problemas o mais depressa possível e gostaríamos de desempenhar um papel ativo na publicação final sobre o problema depois de resolvido.

Exemplo: Fox-IT

Na Fox-IT, consideramos a segurança dos nossos sistemas, da nossa rede e dos nossos produtos de extrema importância. Apesar do grande cuidado que temos com a segurança, ainda podem permanecer pontos fracos. Se encontrou um ponto fraco desses, gostaríamos de ter notícias suas o mais depressa possível para podermos tomar as medidas adequadas o mais rapidamente possível.

Os pontos fracos podem ser descobertos de duas formas: pode deparar-se acidentalmente com algo durante a utilização normal de um ambiente digital, ou pode empenhar-se expressamente em encontrá-los.

A nossa política de divulgação responsável não é um convite a analisar ativamente a nossa rede empresarial para descobrir pontos fracos. Nós próprios monitorizamos a nossa rede empresarial. Isto significa que há uma grande probabilidade de uma análise ser detetada e de o nosso Centro de Operações de Segurança (SOC) efetuar uma investigação, o que poderá resultar em custos desnecessários. É, no entanto, convidado a procurar ativamente vulnerabilidades nos nossos produtos num ambiente offline de não produção e a comunicar-nos as suas descobertas. A nossa responsabilidade para com os nossos clientes significa que a nossa intenção não é incentivar tentativas de pirataria da sua infraestrutura; no entanto, gostaríamos de ter notícias suas o mais depressa possível se forem encontradas vulnerabilidades, para as podermos resolver adequadamente.

Gostaríamos de trabalhar consigo para podermos proteger melhor os nossos clientes e os nossos sistemas.

Pedimos-lhe que:

• Envie as suas descobertas por correio eletrónico o mais depressa possível para security-alert@fox-it.com.

• Não abuse da vulnerabilidade; por exemplo, descarregando, editando ou apagando dados. Levaremos sempre o seu relatório a sério e investigaremos qualquer suspeita de vulnerabilidade, mesmo sem provas.

• Não partilhe o problema com outros até que tenha sido resolvido.

• Não utilize ataques à segurança física, engenharia social ou ferramentas de pirataria, como analisadores de vulnerabilidades.

• Forneça informação adequada para o problema poder ser reproduzido, para que o possamos resolver o mais depressa possível. Normalmente, o endereço IP ou o URL do sistema afetado e uma descrição da vulnerabilidade são suficientes, embora possa ser necessária mais informação para vulnerabilidades mais complexas.

O que prometemos:

• Responderemos ao seu relatório no prazo de três dias úteis, com a nossa avaliação do relatório e uma data prevista de resolução.

• Trataremos o seu relatório de forma confidencial e não partilharemos os seus dados pessoais com terceiros sem a sua permissão. Uma exceção a isto são a polícia e o poder judicial em caso de ação penal ou se a informação for exigida.

• Mantê-lo-emos informado do progresso da solução do problema.

• Na comunicação sobre o problema comunicado, indicaremos o seu nome como a parte que descobriu o problema, se assim o desejar.

• Infelizmente não é possível garantir de antemão que não serão tomadas medidas legais contra si. Esperamos poder considerar cada situação individualmente. Consideramo-nos moralmente obrigados a denunciá-lo se suspeitarmos que o ponto fraco ou os dados estão a ser objeto de abuso, ou que partilhou o conhecimento do ponto fraco com outros. Pode ficar descansado de que uma descoberta acidental no nosso ambiente em linha não levará a uma ação penal.

• Como agradecimento pela sua ajuda, oferecemos uma recompensa por cada relatório de um problema de segurança que não nos seja conhecido. Determinamos o valor da recompensa com base na gravidade da violação e na qualidade do relatório.

Esforçamo-nos por resolver todos os problemas o mais depressa possível, por manter todas as partes envolvidas informadas e gostaríamos de participar em qualquer publicação sobre o problema depois de resolvido.

Exemplo: Bits of Freedom

A nossa dependência da infraestrutura digital está sempre a aumentar. Isto aplica-se à sociedade como um todo, mas também a nós próprios. É por isso nossa opinião que os governos e as organizações (incluindo a nossa) devem comprometer-se fortemente com a segurança da nossa infraestrutura digital. Sabemos que, apesar das nossas melhores intenções e do nosso maior cuidado, podem existir vulnerabilidades nos nossos sistemas. Se encontrar por acaso uma destas fragilidades, gostaríamos muito de ter notícias suas para podermos resolver o problema.

O que esperamos de si

• Quando estiver a investigar um dos nossos sistemas, tenha em conta a proporcionalidade do ataque. Não há necessidade de demonstrar que, ao submeter o nosso sítio ao maior ataque DDoS da história da Internet, o sítio pode ficar inacessível. Nós sabemos isso. Também compreendemos que, se conduzir um buldózer até ao nosso escritório, provavelmente conseguirá agarrar um dos nossos portáteis.

• Este princípio de proporcionalidade também é relevante ao demonstrar a própria vulnerabilidade. Não deve inspecionar nem modificar mais dados do que o estritamente necessário para confirmar a validade da sua descoberta. Por exemplo, se conseguir modificar a nossa página inicial, acrescente apenas uma palavra não controversa em vez de tomar conta de toda a página. Se conseguir obter acesso a uma base de dados, basta mostrar-nos uma lista das tabelas que lá estão, ou talvez o primeiro registo de uma dessas tabelas.

• Uma vulnerabilidade num dos nossos sistemas deve ser comunicada o mais depressa possível enviando um correio eletrónico para security@bof.nl. De preferência, cifre a sua mensagem com OpenPGP. Forneça informação suficiente para podermos reproduzir e investigar o problema.

• A chave pública OpenPGP de security@bof.nl

• Não partilhará o seu conhecimento da vulnerabilidade com outras partes enquanto não tivermos resolvido o problema e ainda estivermos dentro de um prazo razoável desde que comunicou o problema.

• Eliminará todas as informações confidenciais que obteve durante a sua investigação logo que tivermos resolvido a vulnerabilidade.

O que pode esperar de nós

• Responderemos ao seu relatório no prazo de três dias de forma detalhada. Incluiremos uma estimativa do tempo de que precisaremos para resolver o problema. Naturalmente, mantê-lo-emos regularmente informado do nosso progresso.

• Resolveremos a vulnerabilidade o mais depressa possível. Também aqui a proporcionalidade é importante: o tempo necessário para corrigir uma vulnerabilidade depende de vários fatores, entre os quais a gravidade e a complexidade do problema em causa.

• Quando seguir as diretrizes aqui estabelecidas, não tomaremos medidas legais contra si relativamente ao seu relatório.

• É importante para nós dar-lhe crédito pelo que fez - se assim o desejar. Mencionaremos o seu nome numa publicação sobre a vulnerabilidade apenas se concordar.

• Como agradecimento por nos ajudar a proteger melhor os nossos sistemas, gostaríamos de recompensar cada relatório de uma vulnerabilidade que nos era desconhecida na altura. A recompensa dependerá da gravidade da vulnerabilidade e da qualidade do relatório.

• Se encontrar uma vulnerabilidade em software de terceiros que utilizamos e essa vulnerabilidade for abrangida por um programa de bug bounty, não tentaremos reclamar essa recompensa; deve fazê-lo você.