Capítulo 39 — Perícia digital e análise de *malware*: manutenibilidade | Engenharia Perícia digital e análise de malware

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 39 publicada. Mapa, exemplo, EX115.

flowchart TD
  N0["39.1 Por que a manutenibilidade importa"]
  N1["39.2 Estrutura do código"]
  N2["39.3 Conjunto de documentação"]
  N3["39.4 Passagem"]
  N4["39.5 Dívida técnica"]
  N5["39.6 Estabilidade das dependências"]
  N6["39.7 Legibilidade"]
  N7["39.8 Descontinuação"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX115"]

Desenho lógico

flowchart LR
  N0["39.1 Por que a manutenibilidade importa"]
  N1["39.2 Estrutura do código"]
  N2["39.3 Conjunto de documentação"]
  N3["39.4 Passagem"]
  N4["39.5 Dívida técnica"]
  N5["39.6 Estabilidade das dependências"]
  N6["39.7 Legibilidade"]
  N7["39.8 Descontinuação"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX115"]

[39.1 Por que a manutenibilidade importa]
    |
    v
[39.2 Estrutura do código]
    |
    v
[39.3 Conjunto de documentação]
    |
    v
[39.4 Passagem]
    |
    v
[39.5 Dívida técnica]
    |
    v
[39.6 Estabilidade das dependências]
    |
    v
[39.7 Legibilidade]
    |
    v
[39.8 Descontinuação]
    |
    v
[Exemplo resolvido] --> [Exercício EX115]

Objetivos de aprendizagem

Você vai (1) projetar o EvidenceDesk para manutenção de longo prazo; (2) documentar o código e as decisões; (3) planejar a passagem para a equipe de TI de Northfield; (4) gerenciar a dívida técnica.

39.1 Por que a manutenibilidade importa

Os registros de evidências precisam continuar utilizáveis por anos, muito depois de Priya se formar. Um sistema que só o seu autor entende é um passivo para o laboratório e, no fim, para os tribunais que dependem dos seus registros. Recursos e revisões podem chegar muitos anos depois do caso original. Se ninguém conseguir explicar como um registro foi produzido nem conferir a cadeia, a confiabilidade da evidência pode ser contestada mesmo quando nada deu errado. Por isso Priya trata a manutenibilidade como um requisito com seus próprios testes, como verificar se alguém novo consegue gerar uma versão, e não como uma aspiração acrescentada no fim.

39.2 Estrutura do código

Módulos pequenos com finalidade única: registros, cadeia, verificação, ingestão, exportação. Cada módulo tem no topo uma descrição curta explicando o que ele faz e o que ele nunca deve fazer (por exemplo, "a verificação nunca grava em caminhos de evidência"). Dividir por finalidade significa que uma mudança no layout do PDF fica no módulo de exportação e não pode alterar por acidente como os elos da cadeia são calculados. As linhas de "nunca deve fazer" transformam suposições em verificações: um teste varre o módulo de verificação em busca de chamadas de gravação de arquivo e falha se alguma aparecer. Um novo desenvolvedor pode ler o topo de cada módulo e entender a forma do sistema em menos de uma hora.

39.3 Conjunto de documentação

Visão geral da arquitetura, registros de decisão, procedimentos operacionais, relatório de validação e um guia do desenvolvedor explicando como rodar os testes e gerar uma versão. Cada documento serve a um leitor diferente. A visão geral da arquitetura ajuda um desenvolvedor a se orientar; os registros de decisão explicam por que as coisas são como são; os procedimentos guiam a equipe no dia a dia; o relatório de validação sustenta o uso em juízo; o guia do desenvolvedor torna as versões repetíveis. Priya os mantém no mesmo repositório que o código, para que uma mudança e sua documentação possam ser revisadas juntas.

39.4 Passagem

O responsável de TI de Northfield acompanha Priya por duas semanas e depois faz uma pequena mudança e gera uma versão sob a revisão dela, provando que o processo funciona sem ela. A pequena mudança escolhida é acrescentar um campo opcional para o nome do mensageiro que transportou um item, o que mexe em registros, exportação e testes sem pôr a cadeia em risco. O responsável de TI escreve o código, roda o conjunto de testes, atualiza o documento do esquema e gera uma versão seguindo o guia. Cada ponto em que ele precisou fazer uma pergunta a Priya vira uma edição na documentação, para que a próxima pessoa não precise perguntar.

39.5 Dívida técnica

Os atalhos tomados durante o projeto — um caminho fixo no código, um teste ausente — são listados num registro de dívidas com o risco e a correção planejada, e não escondidos. Cada entrada registra o que foi pulado, por quê, o que pode dar errado e quando deve ser corrigido. O caminho fixo, por exemplo, quebraria se o laboratório mudasse o armazenamento, então sua correção é agendada para antes de qualquer mudança planejada. Manter o registro visível permite ao laboratório pesar a dívida contra novas funcionalidades com honestidade, e um auditor pode ver que as fraquezas conhecidas foram gerenciadas, e não ignoradas.

39.6 Estabilidade das dependências

Usar apenas a biblioteca padrão limita o trabalho de atualização ao próprio Python, cuja versão Priya fixa e testa antes de cada atualização. Pacotes de terceiros podem mudar de comportamento, ser abandonados ou ser comprometidos, e cada um é mais uma coisa a revisar e manter atualizada. A biblioteca padrão do Python já oferece cálculo de hashes, tratamento de JSON e acesso a arquivos. Antes de passar para uma nova versão do Python, Priya roda todo o conjunto de testes e os vetores publicados na versão candidata e registra o resultado junto com a mudança. A versão fixada é registrada em todas as notas de versão.

39.7 Legibilidade

Nomes claros e lógica simples valem mais que código engenhoso; um revisor deve entender qualquer função em poucos minutos. Priya reescreve uma função que calculava os elos da cadeia numa única linha densa em quatro passos nomeados: serializar, concatenar, calcular o hash, comparar. Ela não fica mais lenta, e agora um revisor percebe sua finalidade de imediato. Os nomes seguem o domínio, como custody_event e acquisition_digest, para que o código se leia como os procedimentos que a equipe já conhece. Os comentários explicam o porquê, não o quê. Os revisores rejeitam código que não conseguem acompanhar depressa.

39.8 Descontinuação

Funcionalidades que não são mais usadas são removidas por meio de uma mudança registrada, e os registros que elas produziram continuam legíveis. Uma versão inicial suportava um formato de código de barras que o laboratório não usa mais. Remover o leitor simplifica a entrada, mas registros antigos ainda contêm esses códigos de barras, então o módulo de exportação precisa continuar a exibi-los. O registro da mudança declara o que foi removido, por quê e a partir de qual versão, e um teste confirma que os registros antigos ainda são exportados corretamente depois da remoção. O código removido permanece no histórico de versões, então qualquer pessoa ainda pode ver como aqueles códigos de barras antigos eram lidos.

Base de conhecimento

As perguntas comuns dos peritos — por que uma cópia foi bloqueada, como registrar uma exceção — são reunidas num FAQ interno curto que o responsável de TI mantém depois da passagem.

Exemplo resolvido

A primeira mudança do responsável de TI depois da passagem acrescenta um parser para uma nova versão do gerador de imagens. Ele segue o guia do desenvolvedor, acrescenta um teste com um log de exemplo, roda os vetores e o conjunto de integração e gera a versão 1.4.0. Um passo do guia estava confuso; ele o corrige como parte da mesma mudança.

Caso sintético. A passagem é inventada.

Erros e limites

A documentação se degrada; amarre as atualizações à lista de verificação de cada versão.

Exercícios

EX115 — Regra do módulo. Por que declarar o que um módulo nunca deve fazer?
Mostrar critérios de avaliação
Rubrica: 3 = protege invariantes como não gravar em evidências; orienta os revisores; 2 = parcial; 1 = estilo; 0 = nada.
EX116 — Prova da passagem. Como a passagem mostrou que o processo funciona sem Priya?
Mostrar critérios de avaliação
Rubrica: 3 = o responsável de TI fez e lançou uma mudança sob revisão; 2 = parcial; 1 = só treinamento; 0 = nada.
EX117 — Registro de dívidas. O que entra no registro de dívidas?
Mostrar critérios de avaliação
Rubrica: 3 = atalho, risco, correção planejada; 2 = dois; 1 = um; 0 = nada.

Síntese

O software pericial manutenível sobrevive ao seu autor por meio de estrutura, documentação e uma passagem comprovada.

Continue estudando — capítulo 39 de 50

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