Capítulo 14 — Perícia digital e análise de malware: automação
Mapa da aula
Aula 14 publicada. Mapa, exemplo, EX053.
flowchart TD
N0["14.1 O que automatizar"]
N1["14.2 Scripts pequenos"]
N2["14.3 Revisão antes do uso"]
N3["14.4 Somente leitura por projeto"]
N4["14.5 Verificações agendadas"]
N5["14.6 Tratamento de falhas"]
N6["14.7 Registros"]
N7["Compartilhando scripts"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX053"]
Desenho lógico
flowchart LR
N0["14.1 O que automatizar"]
N1["14.2 Scripts pequenos"]
N2["14.3 Revisão antes do uso"]
N3["14.4 Somente leitura por projeto"]
N4["14.5 Verificações agendadas"]
N5["14.6 Tratamento de falhas"]
N6["14.7 Registros"]
N7["Compartilhando scripts"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX053"]
[14.1 O que automatizar]
|
v
[14.2 Scripts pequenos]
|
v
[14.3 Revisão antes do uso]
|
v
[14.4 Somente leitura por projeto]
|
v
[14.5 Verificações agendadas]
|
v
[14.6 Tratamento de falhas]
|
v
[14.7 Registros]
|
v
[Compartilhando scripts]
|
v
[Exemplo resolvido] --> [Exercício EX053]
Objetivos de aprendizagem
Você vai (1) identificar tarefas repetíveis que valem a pena automatizar; (2) escrever scripts simples e revisados; (3) manter a automação segura; (4) registrar as saídas automatizadas.
14.1 O que automatizar
Tarefas repetidas e bem definidas: hashes e conferência de manifestos, verificações de retenção, buscas por número de série USB e junção de linhas do tempo. Passos de julgamento, como decidir uma contenção, continuam manuais. As tarefas escolhidas são as que Sana repetiu durante o caso, como gerar hashes de manifestos e buscar o SN-7731 nos registros de USB. As decisões de contenção e de reinstalação continuam manuais porque pesam o impacto clínico e precisam de uma pessoa que possa responder por elas. Automatizá-las esconderia o julgamento dentro de um código que as gerentes de ala não conseguem questionar. As verificações automatizadas reportam a pessoas, que continuam decidindo o que fazer com cada resultado.
14.2 Scripts pequenos
Os laboratórios deste livro são exemplos: scripts curtos, só com a biblioteca padrão, que leem registros exportados e imprimem resultados. Scripts curtos são fáceis de revisar. Cada laboratório deste livro tem menos de vinte linhas e lê registros exportados sem tocar em nenhum sistema. Scripts curtos podem ser revisados por Owen em minutos, e é isso que torna a revisão realista para uma equipe pequena. Ferramentas maiores só são compradas ou adotadas depois de passarem pela validação do hospital. O leia-me de cada script indica suas entradas e saídas, para que um revisor saiba o que ele deveria tocar.
14.3 Revisão antes do uso
Cada script é revisado por uma segunda pessoa e testado com dados sintéticos de respostas conhecidas antes de tocar em dados do caso. A versão e o hash do script são registrados a cada uso. Testar com dados sintéticos de respostas conhecidas mostra que o script faz o que promete antes de tocar em evidência real. O script de verificação de manifesto, por exemplo, foi testado com um arquivo alterado de propósito para confirmar que ele relata MISMATCH. Registrar a versão e o hash a cada uso liga cada resultado a um código revisado.
14.4 Somente leitura por projeto
Os scripts do caso abrem a evidência em modo somente leitura e gravam a saída numa pasta separada. Um script que poderia modificar a evidência é rejeitado na revisão. Gravar a saída numa pasta separada significa que um erro num script pode produzir um resultado errado, mas nunca uma peça de evidência alterada. A revisão confere os modos de abertura de arquivo no código, e qualquer script que abra a evidência para escrita é devolvido. A pasta de evidências somente leitura acrescenta uma segunda barreira caso um script esteja errado. As pastas de saída são datadas e levam o nome da referência do caso.
14.5 Verificações agendadas
Depois do incidente, a verificação de retenção roda toda semana e a busca por número de série USB roda todo dia, procurando o SN-7731 e qualquer número de série recém-ligado a incidentes. Os alertas vão para a caixa de correio da segurança. Rodar a busca todo dia significa que uma segunda cópia do pendrive da escala, ou o próprio SN-7731 reaparecendo em qualquer PC, seria notada em até um dia. A verificação semanal de retenção detecta configurações que se desviam depois de atualizações. Como a caixa de correio é compartilhada, um alerta continua sendo visto quando alguém da equipe está ausente.
14.6 Tratamento de falhas
Os scripts relatam erros de forma bem visível. Uma falha silenciosa — um script que não imprime nada porque faltava um arquivo — poderia ser confundida com "nada encontrado". Os scripts imprimem a contagem de linhas de entrada processadas. A busca diária pelo número de série que imprimiu input: 0 records é o exemplo do caso: sem a contagem, a saída teria parecido um dia tranquilo. Todo script agora imprime quantas linhas leu e quantas não conseguiu interpretar. Uma execução que não lê nada é tratada como falha a investigar.
14.7 Registros
As saídas automatizadas são guardadas com data, versão do script e hash da entrada. Esses três campos permitem que qualquer pessoa rode de novo, exatamente, uma verificação antiga e veja se uma diferença vem dos dados ou do script. As saídas ficam numa pasta datada ao lado do chamado. Sana cita o arquivo de saída nas notas em vez de redigitar seus números. O hash da entrada liga cada saída à exportação exata que ela leu, mesmo que uma exportação posterior do mesmo sistema seja diferente. Owen confere uma saída por mês, por amostragem, para confirmar que os três campos estão presentes.
Compartilhando scripts
Os scripts revisados ficam numa pasta com controle de versão e um leia-me curto que informa finalidade, entradas, saídas e limites conhecidos. Os colegas usam a cópia compartilhada, e não edições particulares, para que todo caso use a mesma lógica testada.
Exemplo resolvido
A busca diária de Sana pelo número de série imprime input: 4,812 USB records; SN-7731: 0 new sightings (4.812 registros de USB, nenhuma nova ocorrência). Certa manhã, ela imprime input: 0 records — a tarefa de exportação tinha falhado. Como as contagens de entrada aparecem, a falha é detectada e a exportação é corrigida no mesmo dia.
Caso sintético. As saídas são inventadas.
Erros e limites
A automação repete os erros com fidelidade; um script errado dá respostas erradas depressa.
Exercícios
- EX053 — Escolher tarefas. Cite duas tarefas para automatizar e uma para manter manual. Rubrica: 3 = p. ex. hashes, verificação de retenção; decisão de contenção manual; 2 = parcial; 1 = tudo automatizado; 0 = nada.
- EX054 — Revisão. O que acontece antes de um script ser usado com dados do caso? Rubrica: 3 = revisão por uma segunda pessoa, teste sintético com respostas conhecidas, versão/hash registrados; 2 = parcial; 1 = vago; 0 = nada.
- EX055 — Falha silenciosa. Como as contagens de entrada ajudaram? Rubrica: 3 = mostraram 0 registros, expondo a exportação que falhou; 2 = parcial; 1 = vago; 0 = nada.
- EX056 — Somente leitura. Por que os scripts do caso precisam ser somente leitura? Rubrica: 3 = nunca modificar a evidência; saída separada; 2 = parcial; 1 = velocidade; 0 = nada.
Síntese
Automatize o que se repete, revise e teste os scripts, mantenha-os somente leitura e torne as falhas visíveis.
Continue estudando — capítulo 14 de 18
← Capítulo 13 (rascunho) · Índice de capítulos do curso · Capítulo 15 (rascunho) →