Capítulo 10 — Perícia digital e análise de malware: qualidade e solução de problemas
Mapa da aula
Aula 10 publicada. Mapa, exemplo, EX046.
flowchart TD
N0["10.1 Verificações de qualidade"]
N1["10.2 Problema um: entradas ausentes"]
N2["10.3 Problema dois: linhas duplicadas"]
N3["10.4 Problema três: fuso horário"]
N4["10.6 Melhorando os procedimentos"]
N5["10.7 Revisão por colegas"]
N6["Lendo mensagens de erro"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX046"]
Desenho lógico
flowchart LR
N0["10.1 Verificações de qualidade"]
N1["10.2 Problema um: entradas ausentes"]
N2["10.3 Problema dois: linhas duplicadas"]
N3["10.4 Problema três: fuso horário"]
N4["10.6 Melhorando os procedimentos"]
N5["10.7 Revisão por colegas"]
N6["Lendo mensagens de erro"]
N7["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[10.1 Verificações de qualidade]
|
v
[10.2 Problema um: entradas ausentes]
|
v
[10.3 Problema dois: linhas duplicadas]
|
v
[10.4 Problema três: fuso horário]
|
v
[10.6 Melhorando os procedimentos]
|
v
[10.7 Revisão por colegas]
|
v
[Lendo mensagens de erro]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX046]
Objetivos de aprendizagem
Você vai (1) aplicar verificações de qualidade ao trabalho pericial; (2) resolver problemas de exportação e de análise; (3) tratar com honestidade os erros de ferramenta; (4) melhorar os procedimentos a partir dos problemas encontrados.
10.1 Verificações de qualidade
Antes que um relatório saia da equipe: cada constatação cita um registro; cada item de evidência tem hash e entrada de custódia; os horários usam um único fuso; um colega reproduziu os passos principais; o supervisor assinou. No caso da Marlow, cada verificação teve uma função real: a conferência dos hashes detectou o message_trace.csv editado, a regra do fuso único expôs o horário local da exportação do proxy e a reprodução pelo colega confirmou a ligação pela sessão. A lista é curta o bastante para ser aplicada a todo relatório, e Lena a marca no chamado antes de pedir a assinatura de Dev.
10.2 Problema um: entradas ausentes
A primeira exportação de entradas de Lena não mostrava nada antes de 2 de março. Causa: o intervalo padrão do console era de 48 horas. Ela exportou de novo com um intervalo explícito a partir de 1º de março e registrou a correção. Uma exportação de 48 horas feita em 3 de março deixou de fora o dia 1º de março, que estava dentro do escopo aprovado. A verificação de primeira ocorrência depende desse histórico, porque uma linha de base mais curta faz mais endereços parecerem novos. A exportação substituída fica no compartilhamento de evidências com seu próprio hash, marcada como substituída, para que a correção possa ser rastreada por Dev ou por um revisor posterior.
10.3 Problema dois: linhas duplicadas
Juntar duas exportações produziu eventos duplicados. Cada registro tem um identificador de evento único; remover as duplicatas por esse identificador corrigiu as contagens. Lena anota que as contagens do primeiro rascunho estavam erradas e foram corrigidas. As duplicatas surgiram porque as duas exportações cobriam períodos sobrepostos, então alguns eventos apareciam nas duas. Linhas duplicadas inflam contagens como o número de entradas ou de mensagens encaminhadas, que vão direto para o relatório e para a reunião sobre proteção de dados. Remover duplicatas a olho traz o risco de apagar dois eventos reais com o mesmo horário, então o identificador de evento único é a única chave segura.
10.4 Problema três: fuso horário
A exportação do proxy usava o horário local, enquanto as outras usavam UTC, o que deslocava a visita à página em uma hora. A conversão corrigiu a ordem. As notas do caso registram a conversão. Um deslocamento de uma hora importa quando os eventos estão a minutos de distância: a visita à página das 09:10 caiu depois da entrada das 09:14, o que faria a entrada parecer anterior à captura da senha. Essa ordem era impossível para o caso, e foi isso que tornou o erro visível. A conversão é anotada com o fuso original do proxy, para que um revisor possa refazê-la.
10.5 Honestidade sobre os erros
Cada problema é escrito no log do caso com causa e correção. Esconder um erro, mesmo um já corrigido, minaria a confiança se fosse descoberto depois. No log da Marlow, cada problema tem uma entrada: o intervalo de 48 horas, as linhas duplicadas e o fuso do proxy, junto com a edição da cópia de trabalho detectada pelo manifesto. Dev os vê antes do relatório, e os limites do relatório mencionam qualquer correção que tenha afetado um número. Um revisor que encontre depois uma exportação substituída encontra a explicação ao lado dela.
10.6 Melhorando os procedimentos
O runbook agora diz: defina intervalos de datas explícitos; remova duplicatas pelo identificador de evento; converta todas as exportações para UTC antes de juntá-las. Cada linha corresponde a um problema deste caso, então o runbook cresce a partir de evidências, e não de suposições. O intervalo explícito responde às entradas ausentes, a remoção de duplicatas pelo identificador responde às contagens infladas, e a conversão antes da junção responde à visita deslocada. Uma quarta mudança, guardar as notas num arquivo separado das cópias de trabalho, vem da divergência no manifesto. Dev aprova as mudanças, e o próximo caso vai testar se elas funcionam.
10.7 Revisão por colegas
Todo mês, um colega confere uma amostra de constatações com os registros brutos. O colega escolhe constatações ao acaso entre os casos recentes, abre os registros brutos por trás delas e confere se cada uma diz o que a constatação afirma. No caso da Marlow, uma amostra poderia incluir a entrada das 09:14, a criação da regra às 09:20 e a contagem de onze mensagens encaminhadas. As divergências são registradas e discutidas com o analista, e não resolvidas em silêncio. A amostragem mensal detecta desvios na prática que a revisão de um único caso deixaria passar.
Lendo mensagens de erro
Quando um console mostra um erro, Lena copia o texto exato para o log em vez de parafraseá-lo. O texto exato permite que o fornecedor ou um colega procurem a causa e evita uma segunda tentativa frustrada.
Exemplo resolvido
O log de Lena: "13:30 — exportação de entradas incompleta (intervalo padrão de 48 h). Exportado de novo para 1–3 de março; novo hash registrado; exportação antiga mantida e marcada como substituída. Atualização do runbook solicitada."
Caso sintético. Os problemas são inventados.
Erros e limites
As verificações de qualidade detectam erros comuns, não todos os erros; mantenha a humildade nas conclusões.
Exercícios
- EX046 — Lista de qualidade. Liste quatro verificações de qualidade antes da liberação. Rubrica: 3 = constatações citam registros, hashes/custódia, um só fuso, reprodução por colega, assinatura (quatro); 2 = três; 1 = uma; 0 = nada.
- EX047 — Intervalo padrão. O que causou as entradas ausentes, e como foi corrigido? Rubrica: 3 = padrão de 48 horas; nova exportação explícita, novo hash, antiga marcada como substituída; 2 = parcial; 1 = errado; 0 = nada.
- EX048 — Duplicatas. Como as linhas duplicadas foram removidas? Rubrica: 3 = remoção pelo identificador de evento único; correção anotada; 2 = parcial; 1 = apagou a olho; 0 = nada.
- EX049 — Erro de fuso. O que o erro de fuso horário do proxy causou? Rubrica: 3 = deslocou a visita à página em uma hora; convertido para UTC; 2 = parcial; 1 = vago; 0 = nada.
- EX050 — Registrar os erros. Por que registrar no log do caso os erros já corrigidos? Rubrica: 3 = transparência; erros escondidos prejudicam a confiança se descobertos; 2 = parcial; 1 = não precisa; 0 = nada.
Síntese
Confira a qualidade de forma sistemática, corrija os problemas abertamente e transforme-os em procedimentos melhores.
Continue estudando — capítulo 10 de 12
← Capítulo 09 (rascunho) · Índice de capítulos do curso · Capítulo 11 (rascunho) →