Capítulo 21 — Perícia digital e análise de *malware*: requisitos

Mapa da aula

Aula 21 publicada. Mapa, exemplo, EX061.

flowchart TD
  N0["21.1 Partes interessadas"]
  N1["21.2 Requisitos funcionais"]
  N2["21.3 Requisitos não funcionais"]
  N3["21.4 Vínculo com as normas"]
  N4["21.5 Priorização"]
  N5["21.6 Critérios de aceitação"]
  N6["21.7 Controle de mudanças"]
  N7["Rastreabilidade às entrevistas"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX061"]

Desenho lógico

flowchart LR
  N0["21.1 Partes interessadas"]
  N1["21.2 Requisitos funcionais"]
  N2["21.3 Requisitos não funcionais"]
  N3["21.4 Vínculo com as normas"]
  N4["21.5 Priorização"]
  N5["21.6 Critérios de aceitação"]
  N6["21.7 Controle de mudanças"]
  N7["Rastreabilidade às entrevistas"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]

[21.1 Partes interessadas]
    |
    v
[21.2 Requisitos funcionais]
    |
    v
[21.3 Requisitos não funcionais]
    |
    v
[21.4 Vínculo com as normas]
    |
    v
[21.5 Priorização]
    |
    v
[21.6 Critérios de aceitação]
    |
    v
[21.7 Controle de mudanças]
    |
    v
[Rastreabilidade às entrevistas]
    |
    v
[Exemplo resolvido] --> [Exercício EX061]

Objetivos de aprendizagem

Você vai (1) levantar requisitos com as partes interessadas forenses; (2) escrever requisitos funcionais e não funcionais; (3) priorizá-los; (4) vinculá-los às normas.

21.1 Partes interessadas

Os peritos, a gerente do laboratório, a gerente da qualidade, a equipe de TI e, indiretamente, os promotores e os peritos da defesa que vão examinar os registros. Priya entrevista cada grupo e revisa os procedimentos de Northfield. As entrevistas trazem à tona preocupações diferentes. Os peritos temem digitação extra que atrase a geração de imagens. A gerente da qualidade quer prova de que a verificação aconteceu, não apenas uma caixa marcada. A equipe de TI pergunta quem vai aplicar atualizações num servidor offline. Os peritos da defesa, contatados por meio de um ex-profissional da área, dizem que precisam reconstruir a custódia sem pedir favores ao laboratório. Priya escreve cada preocupação como um requisito candidato e anota quem a levantou.

21.2 Requisitos funcionais

FR1: registrar cada item com ID único, descrição, policial responsável pela apreensão e horário. FR2: registrar cada aquisição com ferramenta, versão, algoritmo de hash, digest e perito. FR3: verificar o hash de uma cópia de trabalho contra o digest da aquisição antes de permitir o exame. FR4: manter um log de custódia à prova de adulteração de cada transferência. FR5: exportar um relatório de custódia e de aquisição para a divulgação de provas. Cada requisito funcional nomeia um comportamento observável, não um recurso. O FR2, por exemplo, pode ser testado registrando uma aquisição e conferindo que todos os cinco campos são armazenados e que nenhum pode ficar em branco. Priya numera os requisitos de forma permanente, de modo que o FR3 continua sendo o FR3 mesmo que a redação mude, e testes, defeitos e notas de projeto podem se referir a ele sem ambiguidade.

21.3 Requisitos não funcionais

NFR1: funcionar offline. NFR2: código só com a biblioteca padrão, para permitir auditoria. NFR3: todo registro apenas acrescentável (append-only). NFR4: calcular o hash de uma imagem de 1 TB dentro da janela de geração de imagens no hardware atual. O NFR4 precisa de um número para ser testável. A janela de geração de imagens de Northfield é de cerca de quatro horas, então calcular o hash de 1 TB nesse tempo significa sustentar cerca de 70 MB por segundo, o que uma estação de trabalho moderna faz com folga para o SHA-256. Priya mede isso na máquina de exame mais antiga do laboratório, porque o requisito precisa valer no hardware mais lento ainda em uso, não no mais novo.

21.4 Vínculo com as normas

FR1, FR2 e FR4 apoiam os princípios de documentação e preservação da ISO/IEC 27037; o FR3 apoia as verificações de integridade; o FR5 apoia a divulgação e a revisão. Cada vínculo é escrito na tabela de requisitos. A tabela tem três colunas: o requisito, o princípio que ele apoia e como o vínculo seria demonstrado a um avaliador. Para o FR4, a terceira coluna diz "cadeia de hashes do log de custódia; relatório diário de verificação". Escrever o vínculo de forma explícita impede que o sistema alegue conformidade com uma norma em termos genéricos e mostra aos avaliadores exatamente onde procurar.

21.5 Priorização

Rótulos MoSCoW: Must (FR1–FR4, NFR1, NFR3), Should (FR5, NFR4), Could (leitura de código de barras), Won't neste ano (análise automatizada). A análise automatizada fica em Won't porque arrastaria o EvidenceDesk para a interpretação das evidências, que cabe aos peritos e às ferramentas validadas. A leitura de código de barras é um Could: útil, mas a entrada funciona sem ela. Os rótulos orientam o que se constrói primeiro se o tempo ficar curto. Priya só os revisita por meio do controle de mudanças, para que as prioridades não se desloquem conforme quem pediu por último. Todo Must tem um teste de aceitação antes de a codificação começar.

21.6 Critérios de aceitação

Cada requisito recebe um teste: para o FR3, "o exame é bloqueado quando o digest de uma cópia de trabalho difere, e o bloqueio é registrado no log". Bons critérios de aceitação declaram a preparação, a ação e o resultado esperado. Para o FR3, a preparação é uma cópia de trabalho cujo digest difere do registro da aquisição, a ação é solicitar o exame, e o resultado esperado é uma recusa mais uma entrada de log que nomeia o item, os dois digests e o usuário. Critérios escritos assim se convertem diretamente em testes automatizados.

21.7 Controle de mudanças

Novos pedidos feitos após a aprovação passam por revisão, com o impacto no cronograma e na validação anotado. Um pedido tardio para registrar fotografias dos lacres na entrada parece pequeno, mas mexe no modelo de dados, nas telas de entrada, no dimensionamento do armazenamento e nos testes de validação. O registro da mudança lista cada um desses pontos, o esforço estimado e se o pedido tira um Must do cronograma. A gerente do laboratório decide com essa informação em mãos, e a decisão é registrada com sua justificativa. Os pedidos rejeitados continuam no registro com seus motivos.

Rastreabilidade às entrevistas

Cada requisito registra de qual entrevista ou documento veio. Quando a gerente do laboratório questiona depois o FR4, Priya pode mostrar as três entrevistas com peritos que o levantaram.

Exemplo resolvido

A gerente da qualidade pede "auditoria completa". Priya pergunta o que ela precisa mostrar aos auditores; a resposta é quem mudou o quê e quando, para cada registro. Isso vira o NFR3 mais o FR4, ambos testáveis.

Caso sintético. As declarações das partes interessadas são inventadas.

Erros e limites

Os requisitos capturam o processo de hoje; revise-os depois de um piloto.

Exercícios

• EX061 — Teste do FR3. Escreva o teste de aceitação do FR3.
  Mostrar critérios de avaliação

  Rubrica: 3 = a divergência bloqueia o exame e é registrada no log; 2 = parcial; 1 = vago; 0 = nada.
• EX062 — Pedido vago. Como "auditoria completa" se tornou testável?
  Mostrar critérios de avaliação

  Rubrica: 3 = perguntou a necessidade; virou registros apenas acrescentáveis + log de custódia; 2 = parcial; 1 = aceitou o vago; 0 = nada.
• EX063 — Lista Won't. Por que pôr a análise automatizada em "Won't"?
  Mostrar critérios de avaliação

  Rubrica: 3 = fora do escopo, complicaria a validação; 2 = parcial; 1 = não é útil; 0 = nada.

Síntese

Requisitos testáveis, priorizados e vinculados às normas são a base do EvidenceDesk.

Continue estudando — capítulo 21 de 50

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