Capítulo 11 — Perícia digital e análise de malware: ativos e contexto
Mapa da aula
Aula 11 publicada. Mapa, exemplo, EX031.
flowchart TD
N0["11.1 Por que os ativos importam"]
N1["11.2 Sensibilidade"]
N2["11.3 Valor como evidência"]
N3["11.4 Responsáveis"]
N4["11.5 Contexto"]
N5["11.6 Lacunas"]
N6["11.7 Mantendo-o atualizado"]
N7["Ativos em nuvem"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX031"]
Desenho lógico
flowchart LR
N0["11.1 Por que os ativos importam"]
N1["11.2 Sensibilidade"]
N2["11.3 Valor como evidência"]
N3["11.4 Responsáveis"]
N4["11.5 Contexto"]
N5["11.6 Lacunas"]
N6["11.7 Mantendo-o atualizado"]
N7["Ativos em nuvem"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[11.1 Por que os ativos importam]
|
v
[11.2 Sensibilidade]
|
v
[11.3 Valor como evidência]
|
v
[11.4 Responsáveis]
|
v
[11.5 Contexto]
|
v
[11.6 Lacunas]
|
v
[11.7 Mantendo-o atualizado]
|
v
[Ativos em nuvem]
|
v
[Exemplo resolvido] --> [Exercício EX031]
Objetivos de aprendizagem
Você vai (1) construir um inventário de ativos relevante para a perícia; (2) classificar os ativos por sensibilidade dos dados e valor como evidência; (3) identificar os responsáveis pelos ativos; (4) usar o contexto para priorizar a coleta.
11.1 Por que os ativos importam
Não é possível preservar evidências de sistemas que você nem sabe que existem. O inventário de Alder Falls lista desktops, servidores, dispositivos de rede, serviços em nuvem e seus responsáveis. Durante o caso do CLERK-03, o inventário disse a Renata a qual setor o PC pertencia, quem era o responsável pelo sistema de alvarás que ele conseguia alcançar e para onde iam seus logs. O servidor esquecido do planejamento mostra o inverso: uma máquina que ninguém listou poderia ter sido comprometida sem que ninguém pensasse em verificá-la. O trabalho de inventário parece monótono até o dia em que decide o que será examinado.
11.2 Sensibilidade
O sistema de alvarás guarda nomes, endereços e dados de pagamento dos moradores; o servidor de GIS guarda mapas. Os deveres de proteção de dados recaem sobre os dados pessoais, por isso os sistemas que os guardam ficam mais acima na classificação. Classificar pela sensibilidade também molda a coleta: a evidência copiada do sistema de alvarás pode conter dados pessoais dos moradores, então precisa ser armazenada e acessada com o mesmo cuidado que o original. Jonah anota o nível de sensibilidade de cada ativo ao lado de seu valor como evidência, porque um sistema pode ser importante por um motivo e não pelo outro, e as duas classificações levam a decisões diferentes.
11.3 Valor como evidência
Controladores de domínio, firewalls, servidores de VPN e de proxy guardam evidências sobre muitos sistemas ao mesmo tempo. Ficam no alto da lista de coleta mesmo que guardem poucos dados pessoais. No caso do CLERK-03, o controlador de domínio poderia mostrar se a conta de mfoster foi usada em outros lugares, e o firewall mostrou a grande transferência a partir do desktop de mfoster. Nenhum dos dois guarda os dados dos moradores que tornam o caso grave, mas ambos respondem a perguntas que nenhum desktop isolado consegue responder. Jonah os classifica no alto para que seus logs sejam exportados antes que a rotação de rotina apague o período em questão.
11.4 Responsáveis
Cada ativo tem um responsável de negócio e um responsável técnico. A coleta no sistema de alvarás exige que o gerente de alvarás seja informado. Os responsáveis de negócio decidem se o serviço deles tolera uma coleta ou um isolamento; os responsáveis técnicos sabem onde estão os logs e como exportá-los. Para o banco de dados de alvarás, Jonah procura o responsável técnico para obter as exportações dos logs de acesso, e Renata informa o gerente de alvarás. Registrar os dois nomes no inventário poupa horas quando um incidente começa fora do expediente. Os responsáveis também devem saber que serão avisados antes que uma coleta toque o sistema deles.
11.5 Contexto
O CLERK-03 pertence ao setor de alvarás e consegue alcançar o banco de dados de alvarás. Isso aumenta a prioridade de verificar os logs de acesso do banco de dados. O contexto muda as prioridades depressa. Como o CLERK-03 consegue alcançar o banco de dados de alvarás e o desktop de mfoster exportou um grande relatório de moradores, os logs de acesso do banco de dados sobem para o topo da lista de coleta. Um desktop num departamento sem acesso a dados pessoais continuaria importando, mas não traria a mesma urgência. Jonah registra por que cada prioridade mudou, para que a ordem possa ser justificada depois.
11.6 Lacunas
Jonah encontra um servidor esquecido debaixo de uma mesa no departamento de planejamento, fora do inventário e sem correções desde 2021. Ele é acrescentado e verificado. Um servidor não listado e sem correções é, ao mesmo tempo, um provável ponto de apoio e um ponto cego: ninguém coletava seus logs, ninguém o vigiava e seu responsável era desconhecido. Jonah procura nele os indicadores vistos no CLERK-03, registra o resultado, qualquer que seja, e pergunta ao departamento de planejamento quem o instalou e por quê, para que o inventário registre sua finalidade além de sua existência.
11.7 Mantendo-o atualizado
As atualizações do inventário fazem parte da gestão de mudanças. Em Alder Falls, Jonah propõe que toda requisição de mudança inclua uma verificação do inventário: sistema novo acrescentado, responsável nomeado, destino dos logs registrado; sistema desativado removido, com seus logs retidos pelo período combinado. Sem essa ligação, o inventário fica desatualizado entre as revisões anuais, e a próxima investigação começa com informações erradas. O servidor do planejamento mostra o que acontece sem ela: uma máquina rodando por anos, sem correções de ninguém, invisível a todos os que respondem a incidentes. Uma comparação trimestral do inventário com as concessões do DHCP e as varreduras de rede pega os dispositivos que escaparam do controle de mudanças.
Ativos em nuvem
A prefeitura também usa e-mail em nuvem e um portal de pagamentos hospedado. Os logs desses serviços ficam com os provedores, sob termos contratuais que definem a retenção e o acesso. Jonah registra cada serviço em nuvem no inventário com os tipos de log disponíveis, como solicitá-los e por quanto tempo são guardados, para que os investigadores saibam rapidamente o que pode ser obtido.
Exemplo resolvido
Jonah classifica os alvos de coleta: CLERK-03 (afetado), 10.20.4.12 (origem do logon), servidor do banco de dados de alvarás (dados em risco), controlador de domínio (evidência de contas), firewall (evidência de tráfego). Renata aprova a ordem e acrescenta o servidor esquecido do planejamento como verificação.
Caso sintético. O inventário é inventado.
Erros e limites
Os inventários estão sempre incompletos; varreduras de rede e revisões de logs ajudam a encontrar o que falta.
Exercícios
- EX031 — Ativos ricos em evidência. Por que classificar o controlador de domínio no alto, apesar de ele ter poucos dados pessoais? Rubrica: 3 = guarda evidências sobre muitos sistemas; 2 = parcial; 1 = sem motivo; 0 = nada.
- EX032 — Efeito do contexto. Por que verificar os logs do banco de dados de alvarás? Rubrica: 3 = o CLERK-03 consegue alcançá-lo; dados pessoais em risco; 2 = parcial; 1 = ao acaso; 0 = nada.
- EX033 — Servidor esquecido. O que Jonah encontrou e o que fez? Rubrica: 3 = servidor do planejamento não listado e sem correções; acrescentado e verificado; 2 = parcial; 1 = ignorado; 0 = nada.
Síntese
Um inventário com responsáveis, sensibilidade e valor como evidência diz a quem responde ao incidente o que preservar primeiro.
Continue estudando — capítulo 11 de 30
← Capítulo 10 (rascunho) · Índice de capítulos do curso · Capítulo 12 (rascunho) →