◇ OpenCyber Academy
Engenharia · Capítulo 38 · Português

Capítulo 38 — Perícia digital e análise de *malware*: validação

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

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

Mapa da aula

Aula 38 publicada. Mapa, exemplo, EX112.

flowchart TD
  N0["38.1 O que é validado"]
  N1["38.2 Plano de validação"]
  N2["38.3 Evidências reunidas"]
  N3["38.4 Revisão"]
  N4["38.5 Relatório de validação"]
  N5["38.6 Gatilhos de revalidação"]
  N6["38.7 Usando os resultados do CFTT"]
  N7["Retenção dos registros de validação"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX112"]

Desenho lógico

flowchart LR
  N0["38.1 O que é validado"]
  N1["38.2 Plano de validação"]
  N2["38.3 Evidências reunidas"]
  N3["38.4 Revisão"]
  N4["38.5 Relatório de validação"]
  N5["38.6 Gatilhos de revalidação"]
  N6["38.7 Usando os resultados do CFTT"]
  N7["Retenção dos registros de validação"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX112"]

[38.1 O que é validado]
    |
    v
[38.2 Plano de validação]
    |
    v
[38.3 Evidências reunidas]
    |
    v
[38.4 Revisão]
    |
    v
[38.5 Relatório de validação]
    |
    v
[38.6 Gatilhos de revalidação]
    |
    v
[38.7 Usando os resultados do CFTT]
    |
    v
[Retenção dos registros de validação]
    |
    v
[Exemplo resolvido] --> [Exercício EX112]

Objetivos de aprendizagem

Você vai (1) planejar a validação do EvidenceDesk como parte de um método pericial; (2) escrever um plano de validação; (3) registrar evidências de adequação ao propósito; (4) declarar limitações.

38.1 O que é validado

O EvidenceDesk não analisa evidências, mas faz parte do método pelo qual Northfield as preserva e verifica. A ISO/IEC 27041 dá orientações para assegurar que os métodos sejam adequados e suficientes, incluindo a definição de requisitos e os testes contra eles. Aqui, a validação responde a uma pergunta estreita: o EvidenceDesk registra a custódia de forma confiável e confirma que as imagens armazenadas coincidem com os hashes da aquisição? Ela não diz nada sobre se a interpretação que um perito faz de um arquivo está correta. Manter esse escopo explícito impede que o relatório de validação seja citado em juízo como se cobrisse mais do que cobriu. Priya escreve a declaração de escopo antes de qualquer teste e pede que Hugo a confira.

38.2 Plano de validação

Escopo; requisitos; casos de teste com resultados esperados; critérios de aceitação; ambiente; quem executa; como os resultados são registrados e revisados. Escrever o plano primeiro evita a armadilha comum de decidir o que conta como sucesso depois de ver os resultados. Os critérios de aceitação são números sempre que possível, como zero corrupções não detectadas em todo o teste de exatidão. A parte do plano sobre o ambiente registra o hardware, o sistema operacional e a versão do EvidenceDesk, para que um leitor posterior saiba se os resultados se aplicam à sua configuração. O plano é aprovado pelo gerente da qualidade antes do início da execução.

38.3 Evidências reunidas

Testes com vetores (algoritmo), o teste de exatidão com 200 cópias (detecção), o teste de completude, execuções de integração de ponta a ponta, testes de restauração e testes de adulteração da cadeia. Cada resultado é vinculado a um requisito. Vincular cada resultado a um requisito produz uma tabela de rastreabilidade, com um requisito em cada linha e, ao lado, os testes que o sustentam. Um requisito sem teste fica visível na hora, assim como um teste que não sustenta nada. Na tabela de Priya, o NFR3, sobre registros apenas de acréscimo, tem só os testes de adulteração da cadeia por trás, então ela acrescenta um teste que tenta sobrescrever um registro existente pela interface normal e espera uma recusa.

38.4 Revisão

Um revisor independente — o gerente da qualidade de Northfield mais um perito externo — revisa o plano, os resultados e as limitações antes da aprovação. Quem construiu um sistema tende a testar o que espera que funcione. Um perito externo traz hábitos de outro laboratório e faz perguntas diferentes; aqui, ele pergunta como o EvidenceDesk lida com uma imagem dividida em vários arquivos, algo que o plano não tinha coberto. Os revisores registram seus comentários, Priya responde a cada um por escrito, e a aprovação fica retida até que todos os comentários sejam encerrados.

38.5 Relatório de validação

Resume o que foi testado, os resultados, os desvios, as limitações e o escopo de uso aprovado (por exemplo, "apenas as versões X e Y do gerador de imagens são suportadas"). As limitações são a parte mais omitida e a mais necessária. O relatório declara, por exemplo, que apenas duas versões do gerador de imagens foram testadas e que os resultados em armazenamento de rede não foram medidos. O escopo de uso aprovado transforma essas limitações em regras de operação, para que a equipe saiba que não deve usar o EvidenceDesk fora delas. O relatório é versionado e guardado junto com a versão que ele validou.

38.6 Gatilhos de revalidação

Novas versões do gerador de imagens, mudanças de código que afetem os registros, novas plataformas de armazenamento. Cada gatilho está ligado ao que ele poderia quebrar. Uma nova versão do gerador de imagens pode mudar o formato de log de que a ingestão depende. Uma mudança de código nos registros ou na lógica da cadeia pode alterar como as entradas geram hash. Uma nova plataforma de armazenamento pode mudar o comportamento e a velocidade de leitura. A revalidação não precisa repetir tudo; o plano lista quais testes cada gatilho exige, e uma mudança pequena pode precisar só de um subconjunto. Mudanças não planejadas disparam primeiro uma revisão.

38.7 Usando os resultados do CFTT

Para bloqueadores de gravação e geradores de imagens, Northfield cita os relatórios do CFTT do NIST quando existem e faz suas próprias verificações por amostragem. O programa Computer Forensics Tool Testing do NIST publica relatórios de teste detalhados para versões específicas de ferramentas, o que poupa cada laboratório de repetir os mesmos testes caros. Um relatório cobre apenas a versão testada e as condições usadas, então Northfield confere se o seu modelo e o seu firmware coincidem. Verificações por amostragem no próprio hardware do laboratório, como tentar uma gravação através do bloqueador, confirmam que o resultado publicado se mantém na prática.

Retenção dos registros de validação

Os planos, resultados e aprovações de validação são mantidos enquanto qualquer caso processado sob aquela versão puder ser contestado, o que pode significar muitos anos. Eles são guardados com a versão que cobrem e indexados por versão, para que o laboratório possa responder depressa qual validação se aplicava a um determinado caso.

Exemplo resolvido

O perito externo pergunta se imagens truncadas são detectadas. O plano não tinha esse caso. Priya acrescenta um teste com imagens truncadas em um setor; o EvidenceDesk sinaliza todas por divergência de hash e de tamanho. O relatório registra o caso acrescentado e sua origem na revisão.

Caso sintético. A revisão é inventada.

Erros e limites

A validação cobre as condições testadas; o escopo aprovado precisa ser respeitado no uso.

Exercícios

Síntese

A validação liga requisitos, testes e revisão independente a um escopo de uso aprovado.

Continue estudando — capítulo 38 de 50

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