Capítulo 13 — Perícia digital e análise de malware: cenários de risco
Mapa da aula
Aula 13 publicada. Mapa, exemplo, EX037.
flowchart TD
N0["13.1 Cenários"]
N1["13.2 Probabilidade e impacto"]
N2["13.3 Evidência necessária"]
N3["13.4 Das lacunas às tarefas de prontidão"]
N4["13.5 Priorização"]
N5["13.6 Revisão"]
N6["13.7 Comunicação"]
N7["Teste de mesa"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX037"]
Desenho lógico
flowchart LR
N0["13.1 Cenários"]
N1["13.2 Probabilidade e impacto"]
N2["13.3 Evidência necessária"]
N3["13.4 Das lacunas às tarefas de prontidão"]
N4["13.5 Priorização"]
N5["13.6 Revisão"]
N6["13.7 Comunicação"]
N7["Teste de mesa"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX037"]
[13.1 Cenários]
|
v
[13.2 Probabilidade e impacto]
|
v
[13.3 Evidência necessária]
|
v
[13.4 Das lacunas às tarefas de prontidão]
|
v
[13.5 Priorização]
|
v
[13.6 Revisão]
|
v
[13.7 Comunicação]
|
v
[Teste de mesa]
|
v
[Exemplo resolvido] --> [Exercício EX037]
Objetivos de aprendizagem
Você vai (1) construir cenários de risco relevantes para a prontidão pericial; (2) estimar probabilidade e impacto; (3) identificar a evidência necessária para cada cenário; (4) priorizar o trabalho de prontidão.
13.1 Cenários
Jonah escreve quatro cenários para Alder Falls: ransomware nos servidores de arquivos; roubo de dados por pessoa interna a partir do sistema de alvarás; tomada de conta via phishing; desktop comprometido usado para movimento lateral (como no caso atual). Cada cenário é escrito como uma história curta, com um ponto de entrada, o que o atacante faz e o que a prefeitura perderia. O cenário de movimento lateral espelha o caso atual: um desktop é controlado remotamente, o acesso de admin local se espalha para outros e dados pessoais são exportados. Ancorar um cenário num incidente real mantém o exercício honesto, enquanto os outros cobrem riscos que a prefeitura ainda não enfrentou.
13.2 Probabilidade e impacto
Cada cenário é avaliado numa escala simples, com justificativas. Movimento lateral: provável (senhas de admin local compartilhadas, rede plana); impacto alto (dados de alvarás alcançáveis). Jonah usa três níveis para cada dimensão, baixo, médio e alto, e escreve uma frase que explica cada avaliação, como as senhas de admin local compartilhadas que tornam provável o movimento lateral. As justificativas importam mais que os rótulos: se a prefeitura trocar essas senhas, a avaliação de probabilidade deve cair, e a justificativa escrita mostra por quê. Avaliações sem justificativa não podem ser atualizadas com bom senso.
13.3 Evidência necessária
Para o movimento lateral: logs de segurança dos desktops com tipos e origens de logon, logs internos do firewall e memória da origem e do alvo. Hoje, os logs dos desktops são apenas locais, e os logs do firewall cobrem apenas o tráfego de internet. Listar a evidência de que cada cenário precisa expõe as lacunas com clareza. Para o movimento lateral, duas das três fontes são fracas: os logs dos desktops ficam nos desktops, e o firewall não registra o tráfego entre máquinas internas. O caso atual mostra o custo: os logons no CLERK-03 só ficaram visíveis depois do exame do próprio desktop.
13.4 Das lacunas às tarefas de prontidão
Cada fonte de evidência ausente vira uma tarefa de prontidão com um responsável: encaminhar os logs dos desktops; ativar o registro interno do firewall entre VLANs; pré-instalar ferramentas de captura de memória nos desktops principais. Cada tarefa tem um responsável, uma data-alvo e uma nota curta sobre qual pergunta de cenário ela responde. Encaminhar os logs dos desktops serve ao movimento lateral e ao roubo por pessoa interna; o registro interno do firewall serve ao movimento lateral e ao ransomware; as ferramentas de memória pré-instaladas servem a todos os cenários. As tarefas que servem a vários cenários sobem naturalmente na prioridade. Uma lacuna sem responsável tende a continuar aberta até que o próximo incidente a encontre de novo.
13.5 Priorização
As tarefas que fecham lacunas nos cenários mais prováveis e de maior impacto vêm primeiro. Jonah acrescenta o custo à comparação: uma tarefa barata que fecha uma lacuna num cenário provável e de alto impacto vem primeiro, mesmo que uma tarefa mais cara feche uma lacuna um pouco maior. Encaminhar os logs de segurança dos desktops pontua bem nos três critérios. A ordem resultante é apresentada com seu raciocínio, para que os gestores possam contestá-la. As tarefas que exigem compras novas são agendadas para o próximo ciclo orçamentário, enquanto as mudanças de configuração que a prefeitura pode fazer agora começam de imediato, para que o progresso não espere pelo financiamento.
13.6 Revisão
Os cenários são revisados todo ano e depois dos incidentes. Depois do caso do CLERK-03, Jonah revisa o cenário de movimento lateral com o que foi aprendido: a entrada foi um desktop controlado remotamente, e não um e-mail de phishing, e os dados saíram por um serviço de compartilhamento de arquivos. Atualizar o cenário mantém o plano de prontidão ligado ao modo como os ataques de fato aconteceram aqui, e não apenas ao modo como foram imaginados. Ele data cada revisão e anota qual incidente ou revisão a motivou. Os cenários que ninguém revisitou por um ano são sinalizados na revisão.
13.7 Comunicação
Um resumo de uma página para o gerente de TI: cenários, lacunas, tarefas, custos. O resumo começa pela lacuna que mais afetou o caso atual, os logs dos desktops mantidos apenas localmente, e por seu custo em horas de investigação, antes de listar as outras tarefas. Os gestores decidem sobre orçamentos, por isso cada tarefa mostra um custo aproximado e o cenário a que serve. O detalhe técnico vai para um apêndice destinado à equipe de TI. O resumo termina com um pedido claro: aprovação das três primeiras tarefas e uma data para revisar o progresso. A isso os gestores conseguem dizer sim ou não, ao passo que uma longa lista de lacunas convida ao adiamento.
Teste de mesa
Jonah conduz com a equipe de TI um exercício de mesa de 45 minutos sobre o cenário de ransomware: quem isola, quem captura a memória, onde estão os logs, quem liga para o encarregado de proteção de dados. O exercício revela que ninguém sabe onde fica guardada a ferramenta de captura de memória. Ela é transferida para um pendrive identificado no cofre do escritório de TI, e a ficha do cenário é atualizada com sua localização.
Exemplo resolvido
Para o roubo por pessoa interna, Jonah observa que a aplicação de alvarás registra as exportações por usuário, mas guarda esses registros por apenas 30 dias. A exportação de mfoster teria sido perdida se fosse descoberta um mês depois. Tarefa: ampliar a retenção dos logs da aplicação para 12 meses e encaminhá-los a um ponto central.
Caso sintético. Os cenários são inventados.
Erros e limites
As listas de cenários nunca estão completas; inclua um cenário genérico "desconhecido", atendido por um registro amplo de logs.
Exercícios
- EX037 — Evidência lateral. De que evidência o cenário de movimento lateral precisa? Rubrica: 3 = logs de logon dos desktops, logs internos do firewall, memória; 2 = duas; 1 = uma; 0 = nada.
- EX038 — Tarefa de retenção. Que lacuna do roubo por pessoa interna foi encontrada e corrigida? Rubrica: 3 = retenção de 30 dias dos logs da aplicação; ampliar para 12 meses e encaminhar; 2 = parcial; 1 = vago; 0 = nada.
- EX039 — Cenário desconhecido. Por que incluir um cenário "desconhecido"? Rubrica: 3 = as listas são incompletas; o registro amplo cobre o imprevisto; 2 = parcial; 1 = sem motivo; 0 = nada.
Síntese
Os cenários de risco transformam lacunas de evidência em tarefas de prontidão priorizadas.
Continue estudando — capítulo 13 de 30
← Capítulo 12 (rascunho) · Índice de capítulos do curso · Capítulo 14 (rascunho) →