Capítulo 14 — Engenharia de software
Mapa da aula
Aula 14 publicada. Mapa, exemplo, EX040.
flowchart TD
N0["14.1 Ciclo de vida"]
N1["14.2 Requisitos"]
N2["14.3 Pirâmide de testes"]
N3["14.4 Gestão de mudanças"]
N4["14.5 Defeitos"]
N5["14.6 Documentação"]
N6["14.7 Builds reprodutíveis"]
N7["Análise estática e revisão"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX040"]
Desenho lógico
flowchart LR
N0["14.1 Ciclo de vida"]
N1["14.2 Requisitos"]
N2["14.3 Pirâmide de testes"]
N3["14.4 Gestão de mudanças"]
N4["14.5 Defeitos"]
N5["14.6 Documentação"]
N6["14.7 Builds reprodutíveis"]
N7["Análise estática e revisão"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX040"]
[14.1 Ciclo de vida]
|
v
[14.2 Requisitos]
|
v
[14.3 Pirâmide de testes]
|
v
[14.4 Gestão de mudanças]
|
v
[14.5 Defeitos]
|
v
[14.6 Documentação]
|
v
[14.7 Builds reprodutíveis]
|
v
[Análise estática e revisão]
|
v
[Exemplo resolvido] --> [Exercício EX040]
Objetivos de aprendizagem
Você vai (1) aplicar um ciclo de vida de desenvolvimento a ferramentas forenses; (2) escrever requisitos e testes; (3) gerir mudanças; (4) apoiar a validação de ferramentas.
14.1 Ciclo de vida
Requisitos, projeto, implementação, testes, lançamento, manutenção. Nas ferramentas forenses, cada etapa deixa registros que um validador pode inspecionar. No EvidenceDesk, os registros são uma lista de requisitos, notas de projeto, o histórico de pull requests, os resultados dos testes de cada versão e um log dos defeitos relatados. Um validador que avalia se a ferramenta serve para o trabalho em casos lê esses registros em vez de confiar na palavra do desenvolvedor. As lacunas nos registros contam como riscos: se ninguém consegue mostrar o que foi testado antes de um lançamento, a versão é tratada como não testada.
14.2 Requisitos
"A ferramenta deve calcular o SHA-256 de cada entrada e relatar divergência em relação a um valor armazenado" é testável. "A ferramenta deve ser rápida" não é, até ser quantificado. Quantificar a velocidade poderia ficar assim: 'A ferramenta deve verificar uma imagem de 500 GB a não menos de 300 MB por segundo na estação de trabalho de referência.' Cada requisito recebe um identificador, para que testes e defeitos possam se referir a ele. Os requisitos também cobrem o comportamento em caso de falha, por exemplo 'deve terminar com código de saída diferente de zero e registrar o motivo em log se alguma entrada não puder ser lida', porque é nos modos de falha que as ferramentas forenses mais costumam enganar.
14.3 Pirâmide de testes
Muitos testes unitários, menos testes de integração e alguns testes ponta a ponta sobre conjuntos sintéticos de evidências. O programa Computer Forensics Tool Testing do NIST mostra como os casos de teste se ligam a requisitos específicos. Os testes unitários são rápidos e fixam comportamentos pequenos, como converter corretamente um formato de carimbo de tempo. Os testes de integração verificam se os componentes funcionam juntos, por exemplo se o cálculo de hash e o logging concordam quanto aos nomes de arquivo. Os testes ponta a ponta executam a ferramenta inteira sobre um conjunto de evidências preparado e comparam as saídas com os resultados esperados. Cada teste nomeia o requisito que cobre, de modo que as lacunas de cobertura ficam visíveis.
14.4 Gestão de mudanças
Cada mudança é revisada e ligada a um requisito ou defeito. As versões lançadas têm números de versão e notas de lançamento que listam as mudanças que podem afetar os resultados. As notas de lançamento separam as mudanças cosméticas das que poderiam alterar resultados, como um novo interpretador para um recurso do sistema de arquivos. Os peritos leem o segundo grupo antes de atualizar, e o laboratório pode executar de novo seu conjunto de validação antes de permitir a nova versão no trabalho em casos. Uma mudança sem requisito ou defeito associado é questionada na revisão, porque é em mudanças sem explicação que as regressões silenciosas se escondem.
14.5 Defeitos
Os defeitos são registrados com severidade. Um defeito que possa mudar achados dispara a revisão dos casos anteriores executados com a versão afetada. A severidade depende do que o defeito pode fazer com os achados. Um erro de digitação no texto de ajuda é baixo. Um interpretador que pula algumas entradas de um log é alto, porque poderia esconder evidências. Quando um defeito de alta severidade é confirmado, o laboratório lista todos os casos processados com as versões afetadas, avalia se o defeito poderia ter mudado os resultados e registra o resultado dessa revisão no arquivo de cada caso.
14.6 Documentação
Guia do usuário, limitações conhecidas e resumo da validação acompanham cada versão. As limitações conhecidas são declaradas sem rodeios, por exemplo 'não interpreta atributos NTFS compactados; os arquivos afetados são listados, mas seu conteúdo não tem hash calculado'. O resumo da validação lista o conjunto de testes, a versão testada, os resultados de aprovação e reprovação e a data. Um perito que usa a ferramenta fora do escopo validado precisa justificar essa decisão em suas próprias notas. O guia do usuário inclui exemplos resolvidos com a saída esperada, para que um perito possa confirmar que uma instalação nova se comporta como a validação descreve antes de usá-la num caso.
14.7 Builds reprodutíveis
Fixar versões e registrar o ambiente de build permite que qualquer pessoa reconstrua o mesmo binário a partir do código-fonte. Fixar significa registrar as versões exatas do compilador ou interpretador, de cada dependência e as opções de build. O ambiente de build pode ser capturado como uma imagem de contêiner ou um manifesto detalhado. Duas pessoas que façam o build do mesmo código-fonte no mesmo commit devem obter saídas idênticas byte a byte, de modo que um binário usado num caso pode ser conferido com seu código-fonte anos depois, calculando o hash de um build novo. O registro da versão armazena o hash do binário.
Análise estática e revisão
As verificações automatizadas detectam falhas comuns, como exceções não tratadas ou variáveis não usadas, antes da revisão humana. A revisão de código então se concentra na lógica: esta função faz o que o requisito diz, e cada entrada é validada? Priya guarda os comentários da revisão com a mudança, para que um auditor possa ver o que foi questionado e como foi resolvido. Ao longo de um semestre, sua equipe constata que a revisão detectou mais falhas capazes de afetar resultados do que os testes sozinhos, e ela registra essa observação, com as contagens, no log do projeto.
Exemplo resolvido
Um relatório de defeito: "A exportação da linha do tempo descarta eventos com carimbos de tempo idênticos." Severidade: alta (poderia omitir evidências). Priya o corrige, acrescenta um teste com carimbos de tempo duplicados, lança a versão 1.2.1 e lista as versões afetadas para que Northfield possa revisar os casos.
Caso sintético. O defeito é inventado.
Erros e limites
Um bom processo reduz o risco; não prova que uma ferramenta está correta para entradas não testadas.
Exercícios
- EX040 — Requisito testável. Reescreva "a ferramenta deve ser rápida" de forma testável. Rubrica: 3 = quantificado, p. ex. calcular o hash de 100 GB em menos de 20 min num hardware declarado; 2 = parcial; 1 = inalterado; 0 = nada.
- EX041 — Defeito de alta severidade. Por que o defeito dos carimbos de tempo duplicados era de alta severidade? Rubrica: 3 = poderia omitir evidências dos achados; 2 = parcial; 1 = cosmético; 0 = nada.
- EX042 — Notas de lançamento. O que as notas de lançamento devem incluir para usuários forenses? Rubrica: 3 = mudanças que afetam resultados, versões afetadas; 2 = parcial; 1 = marketing; 0 = nada.
Síntese
A engenharia de software disciplinada dá aos validadores as evidências de que precisam e avisa os laboratórios quando resultados anteriores precisam de revisão.
Continue estudando — capítulo 14 de 50
← Capítulo 13 (rascunho) · Índice de capítulos do curso · Capítulo 15 (rascunho) →