Protecção, Detecção e Resposta

Duração prevista: 120 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: 35 minutos.
• Trabalho prático: 60 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

• Determinar, a partir da tabela de fontes fornecida, que registos recolher primeiro com orçamento limitado, justificando pela detecção que cada fonte permite.
• Reconstituir, a partir dos vinte registos fornecidos, a sequência de acontecimentos e identificar o momento exacto em que o acesso deixa de ser normal.
• Escrever duas regras de detecção com condição, limiar, janela temporal e acção esperada, e estimar o efeito de cada uma em falsos positivos.
• Executar, no ambiente de laboratório, a criação de uma regra de correlação e confirmar que ela dispara com dados de ensaio e não dispara com actividade normal.

Explicação

Detectar exige três coisas: registos que existam, registos que cheguem a um sítio central e alguém que olhe. Falta qualquer uma delas e a detecção não acontece. É comum encontrar instituições com registos em todas as máquinas e nenhuma detecção, porque ninguém os lê e porque ninguém os junta.

Nem tudo se recolhe. Com orçamento e espaço limitados, a ordem que costuma dar melhor retorno é: autenticação (quem entrou, de onde, com que resultado), alterações de privilégios e de contas, registos dos sistemas expostos à internet, tráfego de saída da rede, e registos aplicacionais dos serviços críticos. Autenticação vem primeiro porque quase todos os incidentes passam por lá.

Um SIEM é um sistema que recolhe registos de várias fontes, normaliza-os para um formato comum, correlaciona acontecimentos e gera alertas. O valor não está na ferramenta: está nas regras e em quem as afina. Um SIEM comprado e deixado com as regras de fábrica produz milhares de alertas irrelevantes, a equipa deixa de os ler, e o resultado é pior do que não ter nada — porque existe a ilusão de que se está a detectar.

Uma regra de detecção útil tem quatro elementos: a condição (o que se procura), o limiar (a partir de que quantidade), a janela temporal (em quanto tempo) e a acção (alerta com que prioridade, para quem). Sem limiar e janela, a regra ou dispara sempre ou nunca. Escrever regras é um trabalho de equilíbrio: baixar o limiar aumenta a detecção e aumenta o ruído; subi-lo reduz o ruído e deixa passar. A decisão depende de quantas pessoas há para tratar alertas, e isso é uma conversa de gestão.

Duas condições práticas fazem a diferença na análise. Primeira: horas sincronizadas em todas as máquinas, com fuso declarado — sem isso, a reconstituição da sequência é impossível e a evidência perde valor. Segunda: registos guardados fora da máquina de origem e protegidos contra alteração, porque quem compromete o sistema apaga o rasto local. Num centro de operações de segurança, mesmo pequeno, acrescenta-se uma terceira: uma lista escrita do que se faz em cada tipo de alerta, para que a resposta não dependa de quem está de serviço.

Caso fictício: a madrugada de 3 de Setembro em Muteva

Entre as 02h11 e as 02h48 de 3 de Setembro, a conta «a.chirindza» — administradora de sistemas, que estava de férias — autenticou-se com sucesso no servidor de directório, a partir de um endereço nunca visto, depois de 41 tentativas falhadas em três minutos.

Nos vinte minutos seguintes, foi criada uma conta nova, «svc_update», com privilégios de administração, e o serviço de envio de registos foi parado.

Nada disto gerou alerta. Os registos existiam, estavam nas máquinas, e ninguém os lia. A descoberta foi feita onze dias depois, quando o serviço de cópias falhou por razão não relacionada e alguém foi ver porquê.

Anexo A — Fontes de registo disponíveis e custo estimado (fictício)

Ficha de trabalho: escolher a ordem de recolha com espaço para 200 gigabytes por mês.

Anexo B — Vinte linhas de registo da madrugada de 3 de Setembro (fictícias)

Formato simplificado para leitura em papel: hora (fuso de Maputo, UTC+2), fonte, conta, acontecimento, origem.

02h08 — directório — a.chirindza — autenticação falhada — 41.x.y.z (endereço nunca visto)

02h08 — directório — a.chirindza — autenticação falhada — 41.x.y.z

02h09 — directório — a.chirindza — autenticação falhada (mais 37 tentativas em 3 minutos) — 41.x.y.z

02h11 — directório — a.chirindza — autenticação com sucesso — 41.x.y.z

02h12 — SRV-DIR — a.chirindza — sessão remota iniciada — 41.x.y.z

02h14 — SRV-DIR — a.chirindza — leitura da lista de contas de administração — local

02h19 — SRV-DIR — a.chirindza — criação da conta svc_update — local

02h20 — SRV-DIR — a.chirindza — atribuição de privilégios de administração a svc_update — local

02h23 — SRV-BD — svc_update — sessão iniciada — 10.20.3.30

02h26 — SRV-BD — svc_update — exportação da tabela de processos (41 200 registos) — local

02h31 — rede — — ligação de saída de 10.20.3.30 para destino externo, 2,4 GB transferidos — saída

02h38 — SRV-DIR — a.chirindza — paragem do serviço de envio de registos — local

02h39 — recolector — — deixam de chegar registos de SRV-DIR — —

02h44 — SRV-FIC — svc_update — sessão iniciada — 10.20.3.30

02h46 — SRV-FIC — svc_update — leitura de 3 100 ficheiros do arquivo — local

02h48 — SRV-DIR — a.chirindza — sessão remota terminada — 41.x.y.z

07h02 — directório — j.matola — autenticação com sucesso — 10.20.1.45 (posto habitual)

07h05 — portal — — 1 200 acessos normais de cidadãos — internet

08h30 — directório — r.sitoe — autenticação com sucesso — 10.20.1.12 (posto habitual)

14 de Setembro, 09h10 — cópias — backup_svc — falha da cópia semanal — local

Trabalho prático

Trabalho em grupos de três pessoas, com os anexos A e B em papel, com 60 minutos de trabalho, seguidos de 15 minutos de partilha e síntese em plenário. Desses 60 minutos, 35 são do exercício em papel e 25 são do laboratório descrito mais abaixo. A explicação e a apreciação do produto decorrem nos blocos de exposição e de partilha, e não dentro deste tempo.

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 (10 minutos). Com espaço para 200 gigabytes por mês, escolham as fontes do anexo A a recolher primeiro e justifiquem cada escolha pela detecção que permite. Digam o que deixam de fora e que detecção perdem com isso.

Passo 2 (15 minutos). Reconstituam a sequência do anexo B numa linha temporal. Marquem o momento em que deixa de ser actividade normal e escrevam a frase que justifica essa marcação. Identifiquem os três momentos em que um alerta deveria ter disparado e não disparou.

Passo 3 (10 minutos). Escrevam duas regras de detecção com condição, limiar, janela e acção. Uma delas deve apanhar o início desta sequência. Para cada regra, estimem quantos alertas por semana geraria numa instituição com 62 funcionários e digam se a equipa consegue tratá-los.

Produto esperado: Lista ordenada de fontes com justificação, linha temporal com o momento de ruptura e os três alertas em falta, e duas regras de detecção com estimativa de ruído.

Como o produto é apreciado

• Autenticação e alterações de contas estão entre as primeiras fontes escolhidas; os registos dos postos, que são o maior volume, não ocupam o orçamento todo.
• O momento de ruptura está identificado às 02h11, na autenticação com sucesso após 41 falhas, a partir de endereço nunca visto e com a titular de férias.
• Entre os alertas em falta constam a criação de conta com privilégios às 02h19, a exportação em massa às 02h26 e a paragem do serviço de registos às 02h38.
• As regras têm os quatro elementos; nenhuma fica sem limiar nem sem janela.
• A estimativa de ruído é feita e confrontada com a capacidade real da equipa.

Laboratório em ambiente isolado — Criar e ensaiar uma regra de correlação no recolector de registos

Regras do laboratório, sem excepção. Todos os alvos são máquinas virtuais do próprio laboratório, numa rede isolada e sem ligação à rede de produção da instituição. Nunca se usa como alvo um sistema real da instituição, de outra entidade ou de terceiros na internet, mesmo para «experimentar». Qualquer exercício de teste exige autorização escrita prévia da direcção, com âmbito, janela de tempo e pessoas identificadas. Não se descarrega, não se distribui e não se executa software malicioso real: a análise de ameaças é feita sobre indicadores, registos e descrições fornecidos no material. Não se pede conta pessoal nem pagamento de serviços.

Objectivo: Configurar, no ambiente de laboratório, uma regra que dispare perante múltiplas autenticações falhadas seguidas de sucesso, e confirmar que dispara com os dados de ensaio e não dispara com actividade normal.

Tempo: 25 minutos, dentro do bloco de trabalho prático desta lição. Os minutos do exercício em papel e os minutos do laboratório somam o tempo desse bloco e não se contam duas vezes.

Recursos e versões, preparados antes da sessão

• Máquina virtual «SIEM-LAB» com um recolector de registos de código aberto pré-instalado pelo formador, com interface de regras simples.
• Ficheiro de registos de ensaio «ensaio-03set.log» com as linhas do anexo B em formato normalizado, copiado para SIEM-LAB.
• Segundo ficheiro «ensaio-normal.log» com uma semana de actividade normal fictícia, para medir falsos positivos.
• Folha de laboratório com espaço para a regra escrita, o número de alertas em cada ensaio e a conclusão.

Dependências ainda por preparar, não entregues com a lição

Enquanto qualquer um dos pontos seguintes estiver por preparar, o laboratório regista-se como pendente. Nenhum destes laboratórios foi ainda executado nem testado em sala pela equipa autora: os tempos e os resultados descritos são previsões a confirmar na primeira execução.

• A máquina «SIEM-LAB» e o recolector de registos de código aberto não são entregues com o curso: instalação e escolha da ferramenta são decisão e trabalho da instituição de acolhimento.
• Os ficheiros «ensaio-03set.log» e «ensaio-normal.log» têm de ser montados pelo formador no formato que o recolector escolhido aceitar. O curso entrega as linhas do anexo B e o cenário, não os ficheiros já formatados.
• Sem o recolector, faz-se a análise offline sobre as linhas impressas e regista-se o laboratório como pendente.
• Este laboratório ainda não foi executado numa sala com formandos nem testado pela equipa autora: os 25 minutos previstos e os resultados descritos são estimativa a confirmar na primeira execução, e devem ser corrigidos no guião depois dela.

Preparação prévia, a cargo do formador

• Arrancar SIEM-LAB no dia anterior e confirmar que a interface de regras abre e que a importação de ficheiros funciona.
• Tirar instantâneo «inicial» com o recolector vazio, sem regras criadas.
• Confirmar que a hora da máquina virtual está correcta e com fuso declarado: sem isso a correlação por janela temporal não funciona.
• Confirmar o isolamento da rede virtual.

Passos

1. Importar «ensaio-normal.log» e confirmar que o recolector mostra os acontecimentos e que não existe nenhuma regra activa.
2. Criar a regra escrita no passo 3 da actividade: cinco ou mais autenticações falhadas da mesma conta em dez minutos, seguidas de uma autenticação com sucesso da mesma conta na mesma janela, com acção de alerta de prioridade alta.
3. Correr a regra sobre «ensaio-normal.log» e registar quantos alertas gera. Este número é a estimativa de falsos positivos.
4. Importar «ensaio-03set.log» e correr a mesma regra; registar se o alerta dispara e a que hora corresponde.
5. Criar uma segunda regra para a criação de conta com privilégios de administração fora do horário de expediente e correr sobre os dois ficheiros.
6. Registar na folha as duas regras, os quatro números de alertas obtidos e a conclusão sobre a capacidade de tratamento.

Verificação de sucesso

• A primeira regra dispara sobre «ensaio-03set.log» e o alerta aponta para as 02h11.
• A mesma regra gera zero ou muito poucos alertas sobre «ensaio-normal.log»; se gerar muitos, o grupo ajusta o limiar e volta a correr, registando as duas versões.
• A segunda regra dispara na criação de svc_update às 02h19.
• A folha de laboratório tem as regras escritas e os quatro números registados, assinada pelo grupo.

Reversão ao estado inicial

• Apagar as regras criadas e os ficheiros importados.
• Restaurar o instantâneo «inicial» de SIEM-LAB.
• Confirmar que o recolector volta a abrir sem regras, o que prova a reposição.

Se o ambiente não estiver disponível: análise offline

A análise offline permite estudar o material e chegar às mesmas conclusões no papel, mas não equivale à execução. Quando se recorre a ela, a lição é registada como análise documental e o laboratório fica pendente, para ser reagendado.

• Correr a regra à mão sobre as vinte linhas impressas do anexo B, marcando as linhas que a satisfazem.
• Fazer o mesmo sobre uma amostra impressa de trinta linhas de actividade normal fornecida pelo formador e contar falsos positivos.
• Escrever o ajuste de limiar que faria e recontar à mão.
• Registar a lição como análise documental e o laboratório como pendente, a reagendar.

Síntese em leitura fácil

• Para detectar é preciso ter registos, juntá-los num sítio e alguém olhar. Faltando uma, não há detecção.
• Recolher primeiro autenticação e alterações de contas: quase tudo passa por aí.
• Uma regra precisa de condição, limiar, janela e acção.
• Regra sem afinação enche a equipa de alertas e ninguém lê nenhum.
• Horas certas e registos guardados fora da máquina. Quem entra apaga o que está na máquina.

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. Porque é que às 02h11 o acesso deixa de poder ser tratado como normal, se a autenticação teve sucesso com a palavra-passe certa?
2. A regra nova gerou 180 alertas numa semana de actividade normal. A equipa tem duas pessoas. O que se faz?

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. Porque é que às 02h11 o acesso deixa de poder ser tratado como normal, se a autenticação teve sucesso com a palavra-passe certa?

Resposta: Porque o sucesso vem depois de 41 tentativas falhadas em três minutos, a partir de um endereço nunca visto, de madrugada, numa conta cuja titular está de férias. O sucesso da autenticação prova que a credencial estava correcta, não que era a titular a usá-la.

Comentário: Autenticação com sucesso não é sinónimo de pessoa legítima. A detecção vive do contexto: hora, origem, sequência e comportamento.

Pergunta 2. A regra nova gerou 180 alertas numa semana de actividade normal. A equipa tem duas pessoas. O que se faz?

Resposta: Afina-se antes de a pôr em serviço: subir o limiar, restringir a origens externas, excluir contas de serviço conhecidas ou reduzir a janela. Depois volta-se a medir. Pôr em serviço uma regra que a equipa não consegue tratar leva ao abandono de todos os alertas.

Comentário: A capacidade de resposta faz parte do desenho da detecção. Uma regra boa que ninguém consegue acompanhar é uma regra má na prática.

Referências consultadas

• NIST Cybersecurity Framework — quadro voluntário de segurança cibernética — https://www.nist.gov/cyberframework (consultado em 22 de Setembro de 2026).
  Síntese da equipa: Quadro de adesão voluntária organizado em seis funções: Governar, Identificar, Proteger, Detectar, Responder e Recuperar. Serve para organizar o trabalho de segurança e conversar sobre risco com a direcção; não é lei nem certificação.

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.