Operação Segura e Resposta

Duração: 80 minutos (explicação 20, prática guiada 50, verificação 10). Resultados dos TdR trabalhados: Documentação: diagramas, procedimentos (SOP) e contingência; Incidentes: contenção, análise, recuperação e relatório.

Objectivos

• Redigir um relatório de incidente com factos, cronologia, impacto e acções.
• Transformar lições aprendidas em alterações concretas com responsável e prazo.
• Actualizar um procedimento operacional normalizado (SOP) a partir do incidente.

Do incidente à melhoria

O relatório final responde: o que aconteceu, quando, como foi detectado, o que foi afectado, o que se fez, qual é o estado actual e o que muda. Escreve-se para leitores diferentes: resumo de uma página para a direcção, anexo técnico para a equipa.

Lições aprendidas só valem se virarem acções: «criar regra de alerta para varrimentos», responsável, prazo, forma de verificar. Os SOP (procedimentos normalizados) são actualizados e versionados; o próximo técnico de piquete segue o procedimento em vez de improvisar.

Caso fictício

O incidente 07 (exercício) da DPE fictícia está encerrado. A direcção pede o relatório e as melhorias até ao fim da semana.

Prática guiada em rede isolada

Rede de prática fictícia, criada dentro de um computador de prática com o script base (módulo 1, lição 1). Nunca use estes passos na rede de produção nem contra endereços reais. As saídas mostradas são exemplos didácticos, não resultados de uma execução.

Topologia (descrição em texto)

• Sem rede: trabalho com o registo do incidente 07 da lição anterior (ou o modelo abaixo) e um editor de texto ou papel.

Passos

1. Crie o esqueleto do relatório.

   cat > /tmp/relatorio-07.md <<'EOF'
   # Relatório do incidente 07 (exercício)
   ## Resumo para a direcção (máx. 10 linhas)
   ## Cronologia (hora — facto — fonte)
   ## Impacto (serviços, pessoas, dados)
   ## Acções realizadas (contenção, erradicação, recuperação)
   ## Estado actual
   ## Lições aprendidas e acções (acção — responsável — prazo — verificação)
   ## Anexos técnicos (comandos, capturas, registos)
   EOF

2. Preencha a cronologia a partir do registo, só com factos e fonte de cada linha.

   sed -n '1,20p' /tmp/relatorio-07.md

3. Actualize o SOP «Suspeita de varrimento interno» com os passos que funcionaram; versione-o.

   mkdir -p /tmp/sop && cd /tmp/sop && git init -q && git config user.name 'Tecnico Pratica' && git config user.email 'ti@dpe.example'
   cat > /tmp/sop/varrimento.md <<'EOF'
   # SOP — Suspeita de varrimento interno (v2)
   1. Confirmar com captura e registos (comandos em anexo).
   2. Contactar responsável do equipamento/delegação.
   3. Se não autorizado: quarentena de rede (regra modelo em anexo), sem desligar.
   4. Abrir registo de incidente; informar responsável de TI.
   5. Após análise: erradicar, recuperar, verificar, relatório.
   EOF
   git add varrimento.md && git commit -qm 'SOP varrimento v2 (lições do incidente 07)' && git log --oneline

   Saída de exemplo (didáctica):

   a1 SOP varrimento v2 (lições do incidente 07)

Critérios de sucesso

• Relatório com resumo compreensível por quem não é técnico.
• Pelo menos três acções com responsável, prazo e verificação.
• SOP versionado.

Como desfazer (reversão)

• rm -rf /tmp/sop /tmp/relatorio-07.md

Alternativa em papel: tarefas e respostas esperadas

Reescreva para a direcção: «SYN flood-like scan c/ 30 RST do 10.20.10.10, contido via nft no r2».

«Um computador da delegação tentou ligar-se a 30 serviços do servidor da sede num minuto. Foi isolado da rede às 10h12 sem ser desligado, para análise. Os serviços da sede não foram interrompidos.»

Transforme a lição «demorámos a perceber» numa acção verificável.

Exemplo: «Activar alerta IDS para mais de 10 SYN/10 s da mesma origem interna — responsável: técnico B — prazo: 15 dias — verificação: teste em rede de prática gera alerta».

Verifique o que aprendeu

Questão 1

Qual é a melhor forma de registar uma lição aprendida?

1. «Ter mais cuidado»
2. Acção concreta com responsável, prazo e verificação
3. Uma lista de culpados
4. Não registar para não expor a equipa

Questão 2

Porque se versiona o SOP?

1. Por estética
2. Para saber o que mudou, quando e porquê, e poder voltar atrás
3. Porque o git é obrigatório
4. Para esconder versões

Em leitura fácil

• Depois do problema, escreva o que aconteceu.
• Diga o que vai mudar, quem faz e até quando.
• Actualize o procedimento para a próxima vez.

Fontes

• NIST SP 800-61 Rev. 3 — Incident Response Recommendations (https://csrc.nist.gov/pubs/sp/800/61/r3/final)
• NIST Cybersecurity Framework 2.0 (https://www.nist.gov/cyberframework)
• Git — documentação oficial (https://git-scm.com/doc)