Gestão Avançada do Risco Cibernético

Duração prevista: 90 minutos, em sessão presencial.

Todos os casos, instituições, endereços, registos e números usados nesta lição são fictícios e servem apenas de exercício.

Como o tempo desta lição está distribuído

• Acolhimento e objectivos: 10 minutos.
• Exposição: 25 minutos.
• Trabalho prático: 40 minutos.
• Partilha e síntese: 15 minutos.

Como trabalhamos na sala: um computador por pessoa. Quando não for possível, no máximo duas pessoas por computador, alternando quem executa a meio do trabalho, de modo que ambas façam. Na partilha apresentam dois grupos, com tempo limitado; os restantes entregam por escrito e recebem comentário do formador. Marcar a lição como concluída é registo de aprendizagem e não é registo de assiduidade.

Objectivos da lição

• Distinguir, por escrito e com um exemplo de cada, análise de vulnerabilidades, teste de intrusão e exercício de equipa vermelha, indicando o que cada um produz e o que cada um não prova.
• Priorizar as dez vulnerabilidades da ficha combinando gravidade técnica, exposição do sistema e presença no catálogo de vulnerabilidades exploradas conhecidas da CISA, produzindo uma fila de tratamento justificada.
• Redigir as regras de compromisso de um teste autorizado, com âmbito, alvos, janela temporal, técnicas proibidas, contacto de emergência e critério de paragem imediata.
• Identificar, na minuta fornecida, pelo menos quatro defeitos que tornariam o teste não autorizado ou impossível de documentar.

Explicação

Gestão de vulnerabilidades é um processo contínuo, não uma varredura anual. Tem cinco passos que se repetem: descobrir o que existe (que só funciona se houver inventário), analisar, priorizar, corrigir ou mitigar, e verificar que a correcção ficou feita. O passo que quase sempre falha é o último. Uma vulnerabilidade marcada como «corrigida» sem nova verificação é apenas uma esperança escrita numa folha.

Priorizar é o coração do assunto, porque a lista é sempre maior do que a capacidade da equipa. Três entradas comandam a fila. Primeira, a gravidade técnica, normalmente expressa por uma pontuação de 0 a 10 — é útil, mas descreve a falha em abstracto, não o nosso ambiente. Segunda, a exposição: a mesma falha num servidor publicado na internet e numa máquina de teste isolada não tem o mesmo peso. Terceira, a existência de exploração observada no mundo real; para isso usamos o catálogo de vulnerabilidades exploradas conhecidas mantido pela CISA. Estar nesse catálogo significa que já houve exploração real registada, o que sobe a prioridade. Os prazos de correcção que esse catálogo indica vinculam organismos federais dos Estados Unidos e não instituições moçambicanas: aqui é entrada de decisão, não obrigação legal.

Nem tudo se corrige. Quando não há correcção disponível — por exemplo, aplicação sem contrato de manutenção — mitiga-se: restringir o acesso à rede, colocar atrás de autenticação adicional, desligar a funcionalidade afectada, aumentar a vigilância sobre aquele sistema. A mitigação fica registada com prazo e com o nome de quem a assume, senão torna-se permanente por esquecimento.

Teste de intrusão ético é outra coisa. A análise de vulnerabilidades diz «este serviço parece ter esta falha»; o teste de intrusão tenta demonstrar que a falha é explorável e o que se consegue a partir dela. Três palavras definem a ética aqui: autorização, âmbito e registo. Autorização escrita e prévia da direcção, com identificação das pessoas que executam. Âmbito explícito, com a lista dos alvos permitidos e a indicação clara do que fica de fora. Registo de tudo o que se fez, com data e hora, para que qualquer efeito observado depois possa ser atribuído ou excluído. Sem estes três elementos, a mesma acção técnica deixa de ser teste e passa a ser acesso não autorizado — com as consequências disciplinares e criminais que daí vêm, a apreciar pela área jurídica da instituição e pelas autoridades, nunca pelo técnico.

Um teste de intrusão também não prova o que muita gente julga. Não prova que o sistema é seguro: prova que, naquelas condições, naquele momento e dentro daquele âmbito, encontrou-se ou não se encontrou caminho. Um relatório que conclui «sistema seguro» está mal escrito. O que se escreve é o que foi testado, como, o que se encontrou, com que evidência, e o que ficou por testar.

Caso fictício: pedido de teste na Direcção de Serviços Digitais de Muteva

A direcção de Muteva pede à equipa de informática que «faça um teste de segurança, aproveitando o fim-de-semana, para ver se alguém consegue entrar». O pedido chega por mensagem de telemóvel, sem lista de sistemas e sem indicação de horas.

O administrador de sistemas propõe começar de imediato pelo portal de marcação, que está publicado na internet, e testar também o correio electrónico, que é do fornecedor de nuvem. Propõe ainda experimentar palavras-passe comuns nas contas dos colegas «para mostrar o problema à direcção».

Neste pedido há pelo menos quatro problemas sérios. Testar o serviço do fornecedor de nuvem envolve infra-estrutura de terceiros, que a direcção de Muteva não pode autorizar. Experimentar palavras-passe de contas de colegas sem consentimento e sem âmbito escrito é acesso a contas alheias. Uma mensagem de telemóvel não é autorização documentada. E não há janela temporal nem critério de paragem, pelo que, se o portal cair a meio, ninguém sabe quem manda parar.

Anexo A — Dez vulnerabilidades detectadas na varredura de 14 de Setembro (fictícias)

Os identificadores V-01 a V-10 são internos e fictícios. A coluna «Exploração observada» indica se o caso consta do catálogo de vulnerabilidades exploradas conhecidas.

Anexo B — Minuta de autorização apresentada pela equipa (com defeitos propositados)

Documento fictício. Contém erros deliberados que a actividade pede para encontrar.

«Autorização para teste de segurança. A Direcção autoriza a equipa de informática a realizar testes de segurança aos sistemas da instituição e a outros que se mostrem necessários, durante o mês de Outubro, usando as técnicas que entender adequadas, incluindo testes às contas dos funcionários e aos serviços contratados a fornecedores externos.

Os resultados serão apresentados no final. Em caso de problema, a equipa resolverá internamente. Assinado: a Direcção.»

Trabalho prático

Trabalho em grupos de três pessoas, com os anexos A e B em papel, com 40 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário.

Exercício em papel. Esta parte é análise documental sobre material fornecido. Não é o laboratório e não pode ser registada como prática executada em ambiente.

Passo 1 (15 minutos). Ordenem as dez vulnerabilidades do anexo A numa fila de tratamento. Combinem gravidade, exposição e exploração observada. Escrevam, ao lado de cada uma das três primeiras, a frase que justifica a posição. Atenção a V-09: tem a gravidade mais alta da lista.

Passo 2 (10 minutos). Para V-02, que não tem correcção disponível, escrevam duas mitigações concretas, com responsável e prazo, e digam como se verificaria que a mitigação está mesmo activa.

Passo 3 (15 minutos). Reescrevam a minuta do anexo B em regras de compromisso utilizáveis. Devem constar: alvos permitidos por nome, alvos expressamente excluídos, janela de datas e horas, técnicas proibidas, contacto de emergência com nome e número, critério de paragem imediata, e forma de registo das acções.

Ao reescrever, listem à parte os defeitos da minuta original que corrigiram.

Produto esperado: Uma fila de tratamento justificada, duas mitigações com responsável e prazo para V-02, e uma folha de regras de compromisso completa acompanhada da lista de defeitos corrigidos.

Como o produto é apreciado

• V-09 não está no topo da fila: tem gravidade 9,9 mas está numa máquina isolada, logo a exposição baixa-a.
• V-01 está no topo ou muito perto: está publicada na internet, tem gravidade alta e tem exploração observada.
• As mitigações de V-02 são accionáveis e verificáveis, não são «ter cuidado» nem «avisar os utilizadores».
• As regras de compromisso excluem expressamente os serviços do fornecedor de nuvem e as contas pessoais dos colegas.
• Foram identificados pelo menos quatro defeitos da minuta original, incluindo a autorização aberta a «outros sistemas que se mostrem necessários».
• O grupo escreve que a presença no catálogo da CISA é entrada de priorização e não obrigação legal em Moçambique.

Síntese em leitura fácil

• Descobrir, analisar, priorizar, corrigir, verificar. O passo esquecido é verificar.
• Uma falha muito grave numa máquina isolada é menos urgente do que uma falha média publicada na internet.
• Se já houve exploração real no mundo, a falha sobe na fila.
• O que não se corrige, mitiga-se com prazo e com nome. Mitigação sem prazo torna-se permanente.
• Teste sem autorização escrita, âmbito e registo não é teste: é acesso não autorizado.

Verificação formativa

Estas perguntas não contam para a nota final e não são perguntas do exame final. Servem para a pessoa formanda confirmar o que percebeu.

1. V-09 tem gravidade 9,9 e exploração observada, mas está numa máquina de teste desligada da rede. Deve encabeçar a fila?
2. A minuta autoriza testes «a outros sistemas que se mostrem necessários». Porque é que esta frase é inaceitável?

Respostas comentadas da verificação formativa

As respostas abaixo pertencem às perguntas de verificação formativa desta lição. Não são perguntas nem respostas do exame final e não têm efeito na nota. Tente responder primeiro e só depois compare.

Pergunta 1. V-09 tem gravidade 9,9 e exploração observada, mas está numa máquina de teste desligada da rede. Deve encabeçar a fila?

Resposta: Não. A exposição é nula enquanto a máquina estiver isolada, pelo que o risco actual é baixo. Deve ficar registada e ser corrigida antes de a máquina voltar a ser ligada à rede — essa condição tem de ficar escrita.

Comentário: A pontuação de gravidade descreve a falha, não o nosso ambiente. Priorizar só pela pontuação leva a gastar a equipa onde não há risco real.

Pergunta 2. A minuta autoriza testes «a outros sistemas que se mostrem necessários». Porque é que esta frase é inaceitável?

Resposta: Porque transforma o âmbito em algo indefinido e decidido pelo próprio executante. Sem lista fechada de alvos não é possível provar depois que uma acção estava autorizada, nem excluir a equipa quando algo falha noutro sistema.

Comentário: Âmbito aberto protege ninguém e expõe quem executa. O âmbito existe para proteger a instituição e também o técnico.

Referências consultadas

• CISA Known Exploited Vulnerabilities Catalog — vulnerabilidades exploradas conhecidas — https://www.cisa.gov/known-exploited-vulnerabilities-catalog (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Catálogo público de vulnerabilidades com exploração observada no mundo real. Usa-se como entrada para priorizar correcções: uma falha que consta do catálogo sobe na fila. Os prazos que o catálogo indica aplicam-se a organismos federais dos Estados Unidos e não a instituições moçambicanas.
• OWASP Web Security Testing Guide — guia de testes de segurança de aplicações web — https://owasp.org/projects/web-security-testing-guide (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Guia aberto que descreve, por categorias, o que testar numa aplicação web e como registar o que se encontra. Dá estrutura ao teste autorizado e ao relatório; é uma referência comunitária, não uma norma obrigatória.

Estas referências são quadros e guias técnicos internacionais de adesão voluntária. Não são lei moçambicana, não criam prazos nem obrigações legais e não conferem qualquer certificação.