OpenCyber Academy
Engenharia · Capítulo 22 · Português
Código do curso: OCA-132Capítulo 22: OCA-132-C022

Capítulo 22 — Perícia digital e análise de *malware*: modelos de sistema e de dados

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 22 publicada. Mapa, exemplo, EX064.

flowchart TD
  N0["22.1 Entidades"]
  N1["22.2 Modelo de estados"]
  N2["22.3 Evidência derivada"]
  N3["22.4 Formato de armazenamento"]
  N4["22.5 Tempo"]
  N5["22.6 Identificadores"]
  N6["22.7 Percorrendo o modelo"]
  N7["Validação dos registros"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX064"]

Desenho lógico

flowchart LR
  N0["22.1 Entidades"]
  N1["22.2 Modelo de estados"]
  N2["22.3 Evidência derivada"]
  N3["22.4 Formato de armazenamento"]
  N4["22.5 Tempo"]
  N5["22.6 Identificadores"]
  N6["22.7 Percorrendo o modelo"]
  N7["Validação dos registros"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX064"]

[22.1 Entidades]
    |
    v
[22.2 Modelo de estados]
    |
    v
[22.3 Evidência derivada]
    |
    v
[22.4 Formato de armazenamento]
    |
    v
[22.5 Tempo]
    |
    v
[22.6 Identificadores]
    |
    v
[22.7 Percorrendo o modelo]
    |
    v
[Validação dos registros]
    |
    v
[Exemplo resolvido] --> [Exercício EX064]

Objetivos de aprendizagem

Você vai (1) modelar as entidades das evidências e suas relações; (2) modelar as mudanças de estado de um item; (3) escolher formatos de armazenamento; (4) conferir os modelos contra os fluxos de trabalho reais.

22.1 Entidades

Case, Item, Acquisition, WorkingCopy, CustodyEvent, Person. Um Item pertence a um Case; uma Acquisition pertence a um Item; as WorkingCopies derivam de uma Acquisition; os CustodyEvents registram quem estava com um Item e quando. Person aparece separadamente para que peritos, policiais responsáveis pela apreensão e mensageiros sejam registrados uma única vez e referidos por ID, o que evita variações de grafia do mesmo nome entre os registros. Uma WorkingCopy tem identidade própria porque os peritos podem criar várias a partir de uma aquisição, e cada uma precisa ser rastreável. Priya desenha as entidades como caixas com suas chaves, para que as relações possam ser conferidas num relance.

22.2 Modelo de estados

Um Item passa por estados: registrado → em armazenamento → adquirido → verificado → em exame → devolvido ou retido. As transições só são permitidas em ordem, e cada uma grava um CustodyEvent. Uma verificação que falha leva a cópia a "rejeitada", nunca ao exame. Impor a ordem significa que o sistema rejeita um pedido para levar um item de "registrado" direto para "em exame", porque a aquisição e a verificação seriam puladas. Devolver um item exige um evento de custódia que nomeie quem o recebeu. Uma cópia "rejeitada" continua no registro com seu digest que falhou, porque a evidência de uma falha faz parte do histórico e não pode desaparecer.

22.3 Evidência derivada

As exportações e os arquivos recuperados por carving derivam de uma WorkingCopy; o modelo registra essa linhagem, para que qualquer saída remeta à aquisição original. A linhagem é armazenada como uma referência ao pai em cada objeto derivado: uma imagem recuperada por carving aponta para a cópia de trabalho de onde veio, que aponta para sua aquisição, que aponta para o item. Um anexo de relatório pode, portanto, ser rastreado de volta por todas as etapas. Se mais tarde se descobrir que uma cópia de trabalho está corrompida, uma consulta lista todas as saídas derivadas dela, para que as constatações afetadas possam ser revistas.

22.4 Formato de armazenamento

Os registros são linhas JSON em arquivos apenas acrescentáveis, um por tipo de entidade, com cada linha incluída por hash numa cadeia. O JSON é legível sem software especial, o que ajuda na divulgação de provas. Cada linha contém um registro, mais o hash da linha anterior e o hash do próprio registro. Editar ou apagar uma linha quebra a cadeia daquele ponto em diante, o que a verificação diária relata. Texto simples significa que um perito da defesa pode ler os registros com ferramentas comuns e recalcular a cadeia de forma independente, sem confiar no verificador do próprio EvidenceDesk.

22.5 Tempo

Todos os horários em UTC, em ISO 8601, com a fonte do horário registrada. Registrar a fonte importa porque os horários vêm de lugares diferentes: o relógio do servidor para os eventos que o próprio EvidenceDesk registra, o log da ferramenta de geração de imagens para os horários de aquisição e o depoimento de um policial para o horário da apreensão. Um horário de apreensão copiado de um formulário manuscrito carrega uma certeza diferente da de um carimbo de tempo do servidor, e o registro mantém essa diferença visível. O ISO 8601 com o sufixo Z explícito não deixa dúvida de que um valor está em UTC. Quando uma fonte dá apenas uma data, o registro armazena só a data, em vez de inventar a meia-noite, para que ninguém depois leia nela uma precisão que nunca existiu.

22.6 Identificadores

Os IDs são gerados, nunca reutilizados, e impressos em etiquetas presas aos itens físicos. Os identificadores seguem um padrão como NRF-2026-00417, com um dígito verificador, para que um número digitado errado seja rejeitado em vez de vinculado ao item errado. Nunca são reutilizados, nem mesmo para um item registrado por engano, que é marcado como anulado. As etiquetas trazem o identificador como texto e como código de barras, para que tanto pessoas quanto leitores possam lê-lo. Um identificador anulado continua aparecendo nas buscas, marcado com o motivo da anulação e com quem o anulou.

22.7 Percorrendo o modelo

Priya percorre o modelo com os peritos usando três casos sintéticos passados, procurando etapas que ele não consegue representar. Um caso revela uma lacuna: um celular devolvido ao dono e apreendido de novo mais tarde. O modelo original supunha que os itens saem uma única vez. Priya acrescenta uma transição de reentrada que cria um novo evento de custódia e mantém o histórico anterior, em vez de registrar o celular como um item novo. Percorrer sequências reais pelo modelo encontra problemas que os diagramas sozinhos não mostram. Os peritos aprovam cada percurso.

Validação dos registros

Cada registro é conferido contra um esquema na gravação: campos obrigatórios presentes, horários interpretáveis, digests com o comprimento certo para seu algoritmo. Registros inválidos são rejeitados com uma mensagem, nunca armazenados pela metade. Priya testa o esquema com registros quebrados de propósito, para confirmar que cada regra é acionada.

Exemplo resolvido

O percurso revela que os itens às vezes vão a um laboratório externo para trabalho de chip-off e voltam. O modelo não tinha um estado de "transferência externa". Priya o acrescenta, com campos obrigatórios para a organização receptora e os números dos lacres.

Caso sintético. Os casos são inventados.

Erros e limites

Um modelo omite tudo o que não representa; os percursos revelam lacunas, mas não todas.

Exercícios

Síntese

Um modelo preciso de entidades e estados torna a custódia e a linhagem explícitas e testáveis.

Continue estudando — capítulo 22 de 50

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

Respostas comentadas

EX064. Ela passa a um estado rejeitado e nunca pode transitar para o exame.

EX065. Para que qualquer arquivo exportado ou recuperado por carving possa ser rastreado, por meio de sua cópia de trabalho, até a aquisição original.

EX066. Não havia estado para enviar um item a um laboratório externo; Priya acrescentou um estado de transferência externa que exige a organização receptora e os números dos lacres.