Capítulo 22 — Perícia digital e análise de malware: automação

Mapa da aula

Aula 22 publicada. Mapa, exemplo, EX064.

flowchart TD
  N0["22.1 O que automatizar"]
  N1["22.2 O que não automatizar"]
  N2["22.3 Idempotência"]
  N3["22.4 Registro"]
  N4["22.5 Testes seguros"]
  N5["22.6 Verificações de integridade agendadas"]
  N6["22.7 Tratamento de falhas"]
  N7["Agendamento e dependências"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX064"]

Desenho lógico

flowchart LR
  N0["22.1 O que automatizar"]
  N1["22.2 O que não automatizar"]
  N2["22.3 Idempotência"]
  N3["22.4 Registro"]
  N4["22.5 Testes seguros"]
  N5["22.6 Verificações de integridade agendadas"]
  N6["22.7 Tratamento de falhas"]
  N7["Agendamento e dependências"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]

[22.1 O que automatizar]
    |
    v
[22.2 O que não automatizar]
    |
    v
[22.3 Idempotência]
    |
    v
[22.4 Registro]
    |
    v
[22.5 Testes seguros]
    |
    v
[22.6 Verificações de integridade agendadas]
    |
    v
[22.7 Tratamento de falhas]
    |
    v
[Agendamento e dependências]
    |
    v
[Exemplo resolvido] --> [Exercício EX064]

Objetivos de aprendizagem

Você vai (1) automatizar etapas repetitivas de coleta e verificação; (2) tornar a automação idempotente e registrada; (3) manter as pessoas nos pontos de decisão; (4) testar a automação com segurança.

22.1 O que automatizar

O cálculo de hashes e a criação de manifestos, a exportação de logs de fontes conhecidas, a combinação de linhas do tempo e as verificações diárias de integridade do repositório de evidências. São tarefas repetitivas e sujeitas a erro quando feitas à mão. Essas tarefas têm três características em comum: seguem regras fixas, são feitas com frequência, e uma pessoa que as faz à mão comete pequenos erros difíceis de notar. No caso do CLERK-03, calcular o hash de 47 arquivos e conferir cada valor a olho teria tomado tempo e convidado a um erro de transcrição. Um script faz o mesmo trabalho de forma idêntica a cada vez, e seu log mostra exatamente o que ele fez e quando.

22.2 O que não automatizar

As decisões de isolar, de coletar em dispositivos pessoais ou de reconstruir sistemas ficam com as pessoas, porque exigem julgamento e autoridade. Isolar um servidor pode parar um serviço da prefeitura; coletar num celular pessoal levanta questões legais e de privacidade; reconstruir uma máquina destrói evidências. Cada uma dessas decisões precisa de alguém com autoridade para pesar a situação e assumir a responsabilidade. A automação pode preparar essas decisões, por exemplo reunindo os fatos de que Renata precisa, mas o passo final é dado por uma pessoa nomeada, cuja escolha é registrada com um motivo.

22.3 Idempotência

Executar uma automação duas vezes sobre a mesma entrada deve dar a mesma saída, sem duplicar nem alterar a evidência. O script de manifesto de Jonah produz hashes de manifesto idênticos em execuções repetidas. A idempotência protege a evidência contra um acidente comum: uma tarefa que roda duas vezes por causa de uma nova tentativa ou de um erro de agendamento. Se o script de manifesto acrescentasse entradas duplicadas ou regravasse arquivos na segunda execução, o registro mudaria sem que nada real tivesse mudado. O teste de Jonah executa cada script duas vezes sobre a mesma pasta sintética e compara os dois hashes de manifesto; qualquer diferença reprova o teste.

22.4 Registro

Cada execução automatizada registra o início, as entradas, as saídas com hashes, os erros e a versão. O log de cada execução é ele próprio um registro do caso. Se a tarefa noturna de integridade relatar uma divergência, o log mostra qual arquivo, quais hashes esperado e obtido e qual versão da tarefa produziu o resultado. Os logs são gravados no coletor central, para que uma falha na máquina que executa a tarefa não destrua também o registro do que ela fez. Os logs de execução são guardados pelo mesmo tempo que a evidência que descrevem.

22.5 Testes seguros

As automações são testadas sobre dados sintéticos num ambiente de teste antes de tocar no repositório de evidências. O ambiente de teste reproduz o layout de pastas do repositório de evidências, com arquivos sintéticos de hashes conhecidos. Jonah também testa casos de falha: um arquivo ausente, um arquivo alterado, um arquivo sendo gravado durante a verificação. Só quando a automação trata cada um deles corretamente, relatando em vez de alterar qualquer coisa, ela é apontada para o repositório real. Os resultados de cada execução de teste são guardados com a versão do script que passou, para que a decisão de entrar em produção possa ser rastreada depois.

22.6 Verificações de integridade agendadas

Uma tarefa noturna recalcula os hashes da evidência armazenada e os compara com os manifestos; as divergências geram alerta para Renata. Uma verificação noturna pega as mudanças perto do momento em que acontecem, o que torna a causa mais fácil de encontrar. A divergência encontrada depois que um programa de planilhas regravou uma exportação de log é um exemplo: como foi pega na manhã seguinte, a colega se lembrou da ação, e o original pôde ser restaurado a partir do backup de gravação única. Verificações semanais teriam deixado um intervalo maior. Cada alerta só é encerrado com uma causa registrada e a ação tomada.

22.7 Tratamento de falhas

Se uma etapa falha, a automação para e relata, em vez de continuar com dados parciais. Continuar depois de uma falha poderia produzir um manifesto com aparência de completo, mas sem alguns arquivos, ou um relatório de integridade que pula em silêncio uma parte do repositório. Parar e relatar torna a falha visível na hora. Os scripts de Jonah terminam com uma mensagem clara que nomeia a etapa que falhou e deixam as saídas parciais marcadas como incompletas, para que ninguém as tome por trabalho concluído. Uma nova execução começa do início, nunca do meio de uma execução que falhou.

Agendamento e dependências

A tarefa noturna de integridade roda depois que os backups terminam, para verificar a cópia armazenada, e não um arquivo em gravação. Jonah acrescenta uma dependência para que a tarefa espere o sinal de sucesso do backup e gere alerta se o backup falhar. Nos testes, verificações sobre arquivos gravados pela metade tinham produzido falsas divergências, o que desperdiçou uma hora de investigação até que a causa fosse encontrada e documentada.

Exemplo resolvido

A verificação noturna relata uma divergência numa exportação de log. A investigação mostra que o arquivo foi movido e regravado pelo programa de planilhas de uma colega, o que mudou as quebras de linha. O original é restaurado a partir do backup de gravação única; a pasta de evidências passa a ser somente leitura para toda a equipe, exceto para a custodiante das evidências.

Caso sintético. A divergência é inventada.

Erros e limites

A automação repete os erros com a mesma eficiência que os passos corretos; revise sua lógica e suas saídas com regularidade.

Exercícios

• EX064 — Automatizar ou não. Dê uma tarefa a automatizar e uma a deixar com as pessoas.
  Mostrar critérios de avaliação

  Rubrica: 3 = p. ex., manifestos vs. decisões de reconstrução, com motivo; 2 = só exemplos; 1 = invertido; 0 = nada.
• EX065 — Idempotente. O que idempotente significa para o script de Jonah?
  Mostrar critérios de avaliação

  Rubrica: 3 = mesmo hash de manifesto em execuções repetidas; sem duplicatas nem mudanças; 2 = parcial; 1 = rápido; 0 = nada.
• EX066 — Divergência noturna. O que causou a divergência, e o que mudou?
  Mostrar critérios de avaliação

  Rubrica: 3 = a regravação pela planilha mudou as quebras de linha; restauração, pasta somente leitura; 2 = parcial; 1 = vago; 0 = nada.

Síntese

Automatize o trabalho repetitivo de integridade de forma idempotente e com logs; deixe as decisões de julgamento com as pessoas.

Continue estudando — capítulo 22 de 30

← Capítulo 21 (rascunho) · Índice de capítulos do curso · Capítulo 23 (rascunho) →