Aviso: O original desta página foi escrito em neerlandês. Esta página foi traduzida automaticamente para outras línguas utilizando DeepL. Isto pode resultar em diferenças de nuance, tom e significado. Em caso de dúvida, consulta sempre primeiro a versão neerlandesa. Devido ao elevado custo das traduções, esta página pode ficar aquém da versão neerlandesa em termos de conteúdo. Consideramos a versão neerlandesa desta página como líder.
A Internet Cleanup Foundation tem um código de conduta que estabelece os princípios básicos sobre as medidas que são ou não publicadas.
Esta página explora esta questão com exemplos práticos.
Medições públicas com um objetivo público
Em princípio, a Segurança Básica mede a segurança ao nível básico. Isto pode ser publicado livremente sem aumentar o risco de abuso para além do que já existe. Considera medir onde faltam medidas de segurança comuns.
A base de dados do Basisbeveiliging.nl contém mais de 10 milhões de medições únicas. Todas as medições da base de dados podem ser publicadas na íntegra em qualquer altura, ou divulgadas, sem criar novos riscos que um atacante possa explorar.
Uma organização com uma política de segurança adequada será sempre verde em matéria de segurança básica: as medidas em si não são novidade nem chocantes, mas a falta de aplicação pode por vezes ser.
As medidas de segurança básica estão na área do hacking ético e dos testes de segurança. Existem fortes semelhanças com os primeiros passos dos testes de segurança profissionais, como o mapeamento da superfície de ataque. Isto abrange domínios, portas e software. Trata-se de informação pública que é fácil de recolher em grande escala. Há muitas empresas que o fazem e o oferecem a um custo muito baixo ou mesmo publicamente e de graça.
A Basic Security nunca publica vulnerabilidades graves ou críticas. Deixa isso para outras organizações, como empresas profissionais de testes de segurança como Secura, Zerocopter ou organizações voluntárias como a DIVD.
Resultados publicáveis
A Internet Cleanup Foundation publica informações sobre vulnerabilidades e medidas de segurança em falta. Fá-lo com o objetivo de corrigir essas vulnerabilidades. Com base no código de conduta, determina se uma vulnerabilidade pode ser publicada. É aqui que são considerados o interesse público, a proporcionalidade e a subsidiariedade.
As vulnerabilidades publicáveis estão disponíveis publicamente para todos no sítio Web de segurança básica. Também podes aceder a este site automaticamente.
As vulnerabilidades publicáveis são classificadas por risco. Trata-se de uma classificação de risco diferente da que é comum no mundo da segurança porque o espetro de medidas é diferente. O espetro da segurança básica tem quatro graus que são escalonados de acordo com o que pode potencialmente correr mal. Isto contrasta com os testes de segurança habituais, que colocam os mesmos resultados contra coisas que realmente correm mal. Isto contrasta com os testes de segurança habituais, que confrontam os mesmos resultados com coisas que estão realmente a correr mal neste momento. Enquanto a Segurança Básica avalia algo como “alto”, num teste de segurança profissional será classificado como “info”, “baixo” ou, num caso especial, como “médio”, dependendo do objetivo do teste.
As gradações da segurança básica mudam ao longo do tempo, para elevar lentamente a fasquia da segurança básica. Quando uma medida é laranja este ano, pode ser vermelha no próximo ano para chamar mais atenção para ela. Por exemplo, a aplicação do security.txt não é obrigatória até meados de 2023, pelo que, nessa altura, nem todas as organizações estarão a aplicar esta norma. No entanto, em meados de 2024, isso seria inaceitável, uma vez que terão tido um ano para a aplicar. Encontra mais informações sobre este assunto na política de medição.
Estas são as quatro gradações que aplicamos:
Vermelho: representa uma vulnerabilidade de alto risco. Neste caso, trata-se de uma imperfeição que precisa de ser corrigida. Considera, por exemplo, uma encriptação fraca. A fuga de informações sobre a versão (leia-se: dizer a um atacante o que executar) e coisas do género.
Laranja: diz frequentemente respeito a instituições e deficiências administrativas. Além disso, novas medições que deveriam eventualmente ser vermelhas, mas que são classificadas como laranja para introdução: para tornar a medição visível e acionável nas organizações responsáveis.
Verde (baixo): Uma medida que envolve um desvio na segurança que tem muito pouco impacto (ainda), porque há poucas pessoas que podem sofrer este problema e, nesse caso, muitas vezes já estão expostas a uma vasta gama de questões mais graves. Este nível é também utilizado para medições que podem implicar obrigações legais no futuro, mas que não são muito comuns atualmente.
Verde (ok): Uma medição correta: a segurança é garantida neste ponto.
Os resultados são sempre acompanhados de documentação, referências e, sempre que possível, de uma ligação para uma segunda opinião, na qual pode ser efectuado um novo teste. Estes elementos também constam da política de medição. Isto permite conhecer a relevância de uma nova descoberta e verificar imediatamente se a vulnerabilidade foi corrigida.
Exemplos de vulnerabilidades publicáveis incluem: encriptação em falta, DNSSEC em falta, security.txt em falta, localização física do serviço, aplicação de RPKI, informações sobre a versão pública.
Todas as informações contidas nos sítios Web, incluindo todas as medições, estão sujeitas à nossa declaração de exoneração de responsabilidade. Por conseguinte, a utilização destes resultados é sempre feita por tua conta e risco. Fazemos o nosso melhor para publicar sempre medidas corretas e actualizadas, lê mais sobre isto na política de medidas.
Como são publicadas as novas medições
Antes de uma nova medição ser publicada, é primeiro anunciada às organizações de cúpula, para que estas possam tomar medidas em relação à mesma. Nessa altura, os próprios resultados da medição ainda não são, muitas vezes, esclarecedores. Pelo menos um mês depois, a medição torna-se visível e pública.
Segue-se um período experimental durante o qual a medição será classificada, no máximo, como laranja. Durante este período experimental, todos podem reagir à medida e esta pode ser reforçada. Este período dura normalmente um ou dois meses. Após este período, a medição é reescalonada e, possivelmente, definida para vermelho.
Exemplo de cenário de vulnerabilidade publicável
Uma organização precisa de um sítio Web. Este sítio Web é entregue por uma agência de desenvolvimento. Esta agência de desenvolvimento utiliza software normalizado e concentra-se principalmente na funcionalidade e na informação.
O sítio Web está a ser lançado, mas a segurança ainda não foi abordada. Por exemplo, o sítio ainda não está acessível através de uma ligação encriptada (1: https), não há garantias de que o nome de domínio pertença ao endereço IP do sítio (2: DNSSEC) e há um painel de gestão público (3: painel de início de sessão) que mostra que se trata da versão 7.0.2 do software (4: informações sobre a versão).
Este caso dá a um atacante todo o tipo de manípulos que podem ser facilmente evitados. Um atacante precisa de pouco ou nenhum esforço para os encontrar, e há muito que automatizou este conhecimento para causar o máximo de danos possível desta forma.
Neste estudo de caso, um atacante pode explorar as vulnerabilidades das seguintes formas: pode ler juntamente com o tráfego da Internet na mesma rede, como um hotspot Wi-Fi, porque falta o https (1: https), na mesma rede o atacante pode redirecionar o tráfego para uma página falsa (2: dnssec), pode fazer tentativas de iniciar sessão na página de gestão em qualquer parte do mundo (3: painel de início de sessão) e procurar e aplicar vulnerabilidades conhecidas publicamente em qualquer parte do mundo (4: informações sobre a versão).
Os atacantes já têm esta informação, por isso é importante que as pessoas que têm de se defender também a tenham. Em todos estes ataques, há uma base de abertura e de bom profissionalismo.
Quando os quadros de segurança e os quadros de normas conhecidos são seguidos de forma competente, não existem todas estas vulnerabilidades. Pensa na ISO27002, NEN7510, Baseline Information Security Government e afins. Tem em atenção que estes quadros não são práticos e deixam que cada um meça e meça as suas próprias soluções. Como resultado, na mesma situação, um principiante escreverá um plano diferente em termos de conteúdo do que um profissional. Na segurança básica, estabelecemos uma determinada fasquia que é relevante em todos os casos. Alguns acham esta fasquia demasiado alta, outros acham-na demasiado baixa. Em todo o caso, é a base.
Vulnerabilidades que não podem ser publicadas
A segurança básica centra-se nos requisitos básicos de segurança.
Os voluntários da fundação também encontram, por vezes, vulnerabilidades graves. Isto é um subproduto e não o objetivo da fundação. Eis como lidamos com isto. As pesquisas activas de vulnerabilidades graves são feitas pela organização amiga DIVD. Assim, a segurança da base nunca procura ativamente por vulnerabilidades graves.
Se encontrarmos acidentalmente uma vulnerabilidade grave, segue abaixo a forma como lidamos com ela.
Quando se suspeita de uma vulnerabilidade grave, a abordagem que proporciona a maior segurança no mais curto espaço de tempo é considerada aqui numa base caso a caso. Há uma série de opções que são consideradas:
- Se se tratar de uma nova vulnerabilidade que ainda não é conhecida (não é um CVE), existem várias opções. Depende de onde a vulnerabilidade foi identificada e da sua gravidade. São considerados os seguintes caminhos:
- Passa para o Instituto Holandês de Divulgação de Vulnerabilidades. Eles têm a infraestrutura para identificar as vítimas desta vulnerabilidade e avisar sobre a fuga. Esta ação é a nossa opção preferida.
- Quando o criador do software tem um processo adequado de Divulgação Coordenada de Vulnerabilidades, esta vulnerabilidade também é transmitida diretamente ao criador. Isto só acontece quando pode ser feito de forma confidencial.
- As regras básicas da Divulgação Coordenada de Vulnerabilidades são aplicadas para notificar a parte vulnerável.
- Quando se trata de uma vulnerabilidade conhecida, são seguidas as regras básicas da Divulgação Coordenada de Vulnerabilidades. Examina-se se a organização dispõe de um processo deste tipo.
- Se não existir um processo de CVD, é contactada a organização de segurança a que pertence. Trata-se, por exemplo, do Serviço de Segurança da Informação para os municípios ou do Centro Nacional de Cibersegurança para o governo nacional.
- Está a ser considerada a possibilidade de transmitir o relatório através da Linha Direta de Segurança.
- A comunicação em torno da vulnerabilidade grave será considerada de acordo com as regras básicas do CVD. Uma vez que encontrar e publicar novas vulnerabilidades não é o nosso objetivo, a comunicação sobre novas vulnerabilidades, se alguma vez ocorrer, será provavelmente feita através da parte a quem foi comunicada, da Linha Direta de Segurança, da DIVD ou de uma organização semelhante.
Exemplos de vulnerabilidades não publicáveis são: Injeção de SQL, cross-site scripting, uso de senhas fracas, senhas vazadas, execução remota de código, buffer overflows e CVEs.
Exemplo de cenário de vulnerabilidade grave
Este exemplo baseia-se num cenário real e numa vulnerabilidade conhecida: desativar um módulo que tornava os ficheiros contendo palavras-passe diretamente legíveis na página inicial de um sítio (desactivando o PHP). Trata-se de um erro de configuração.
Um voluntário está a pesquisar informações em basicsecurity.co.uk. O voluntário vê um site: “oud.belangrijkeoganisation.nl”, que pode, portanto, ter uma segurança fraca. O voluntário fica interessado e visita o sítio.
Ao visitar o site, parece que algo está errado com a configuração: o código-fonte do site pode ser visto, em vez de um site bonito. Este código fonte contém uma palavra-passe da base de dados e ligações a ficheiros sensíveis.
O voluntário sabe que não é essa a intenção e consulta outros voluntários sobre o que é sensato fazer. Trata-se de uma vulnerabilidade individual e conhecida, pelo que as regras da CVD são seguidas.
O voluntário contacta a organização de segurança que pertence ao sítio Web. Troca informações sobre a vulnerabilidade e a organização segue os processos internos associados à CVD e à resolução da vulnerabilidade.
A organização resolveu a vulnerabilidade dentro de um prazo previsível. Por vezes, a organização opta por recompensar o repórter com um brinde ou uma entrada no hall da fama.