Capítulo 16 — Engenharia de sistemas
Mapa da aula
Aula 16 publicada. Mapa, exemplo, EX046.
flowchart TD
N0["16.1 O laboratório como sistema"]
N1["16.2 Interfaces"]
N2["16.3 Rastreabilidade de requisitos"]
N3["16.4 Compromissos entre alternativas"]
N4["16.5 Partes interessadas"]
N5["16.6 Ciclo de vida"]
N6["16.7 Fatores humanos"]
N7["Modos de falha"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX046"]
Desenho lógico
flowchart LR
N0["16.1 O laboratório como sistema"]
N1["16.2 Interfaces"]
N2["16.3 Rastreabilidade de requisitos"]
N3["16.4 Compromissos entre alternativas"]
N4["16.5 Partes interessadas"]
N5["16.6 Ciclo de vida"]
N6["16.7 Fatores humanos"]
N7["Modos de falha"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX046"]
[16.1 O laboratório como sistema]
|
v
[16.2 Interfaces]
|
v
[16.3 Rastreabilidade de requisitos]
|
v
[16.4 Compromissos entre alternativas]
|
v
[16.5 Partes interessadas]
|
v
[16.6 Ciclo de vida]
|
v
[16.7 Fatores humanos]
|
v
[Modos de falha]
|
v
[Exemplo resolvido] --> [Exercício EX046]
Objetivos de aprendizagem
Você vai (1) ver um laboratório forense como um sistema de pessoas, processos e ferramentas; (2) definir interfaces entre etapas; (3) rastrear requisitos através do sistema; (4) gerir compromissos entre alternativas.
16.1 O laboratório como sistema
As evidências passam da apreensão à entrada, à geração de imagem, ao exame, à revisão, ao relatório e ao armazenamento. Cada etapa tem entradas, saídas, responsáveis e modos de falha. A ISO/IEC 27043 descreve os processos de investigação de forma escalonada semelhante, da prontidão até o encerramento. Os modos de falha diferem por etapa. Na entrada, um item pode ser rotulado errado. Na geração de imagem, o bloqueador de escrita pode ser dispensado. No exame, um interpretador pode estar desatualizado, e no armazenamento um disco pode falhar. Priya desenha o fluxo como caixas e setas, escreve sob cada caixa a falha mais provável e seu controle e depois pergunta a Hugo qual controle ele de fato já viu falhar. As respostas dele reordenam as prioridades dela.
16.2 Interfaces
A saída da geração de imagem (um arquivo de imagem, seu hash, um log de aquisição) é a entrada do exame. Definir essa interface com precisão — formatos, campos obrigatórios — evita erros quando o trabalho muda de mãos. A saída da geração de imagem em Northfield era uma pasta cujo conteúdo dependia da ferramenta usada. Priya define um manifesto com campos fixos: ID do item, nomes dos arquivos de imagem, algoritmo de hash, valor do hash, ferramenta, versão, perito e horários de início e de fim. O exame se recusa a começar até que o manifesto seja validado. Um campo ausente, como o nome do algoritmo, bloqueia a passagem em vez de ser adivinhado depois.
16.3 Rastreabilidade de requisitos
Uma matriz de rastreabilidade liga cada requisito (p. ex., "toda imagem verificada antes do exame") ao elemento de projeto que o atende e ao teste que o demonstra. Uma linha diz: R-07, toda imagem verificada antes do exame; projeto, a fila de exame só aceita itens cujo estado de verificação é 'match'; teste, T-21 submete um item não verificado e espera uma recusa. Quando um auditor pergunta como o laboratório garante a verificação, a matriz responde com um resultado de teste, não com uma promessa. As linhas sem teste são lacunas visíveis.
16.4 Compromissos entre alternativas
Triagem mais rápida versus minúcia; armazenamento central versus estações de trabalho locais; ferramentas de fornecedores versus scripts próprios. Priya registra cada decisão com sua razão e as alternativas rejeitadas. Sobre armazenamento central versus local, Priya anota que o armazenamento central simplifica os backups e o logging de acesso, mas precisa de uma rede rápida, enquanto as estações de trabalho locais são rápidas, mas espalham as evidências. Ela escolhe o armazenamento central com pastas de cache locais que são limpas após cada caso, registra a melhoria de rede que isso exige e lista as condições sob as quais a decisão deve ser revista.
16.5 Partes interessadas
Peritos, gestores, promotores, peritos da defesa e auditores querem coisas diferentes. Um bom projeto declara quais necessidades atende e quais não atende. Os peritos querem velocidade e menos passos manuais. Os gestores querem números de produtividade. Os promotores querem relatórios claros, e os peritos da defesa querem detalhes suficientes para testar o trabalho. Os auditores querem evidências de que os procedimentos foram seguidos. O projeto de Priya declara que o EvidenceDesk atende primeiro à integridade e à rastreabilidade e depois à velocidade, e não tenta substituir o sistema de gestão de casos, o que mantém o escopo realista.
16.6 Ciclo de vida
Os sistemas envelhecem: os formatos mudam, os discos crescem, a equipe se renova. O projeto inclui pontos de revisão. Os pontos de revisão são agendados anualmente e também disparados por eventos, como a chegada em volume de um novo formato de evidência, a saída de um membro-chave da equipe ou um grande lançamento de sistema operacional. Cada revisão verifica se os requisitos originais continuam válidos. Um sistema projetado para laptops pode precisar ser repensado quando as evidências de celulares e de nuvem dominam a entrada, e perceber isso cedo sai mais barato do que uma reconstrução em crise. Cada revisão termina com uma nota datada, mesmo quando nada muda.
16.7 Fatores humanos
Interfaces que tornam fácil a ação segura — a verificação como etapa padrão, não como botão opcional — reduzem os erros. Se a verificação é um botão separado, peritos ocupados às vezes a pularão. Se a etapa de importação executa a verificação automaticamente e se recusa a continuar em caso de divergência, pulá-la torna-se impossível sem uma exceção deliberada e registrada. Priya também projeta mensagens de erro que dizem o que fazer em seguida, como 'gere de novo a imagem do item' ou 'contate o responsável pelas evidências', em vez de simplesmente 'erro de hash'. As exceções exigem uma justificativa digitada pelo perito.
Modos de falha
Em cada etapa, Priya pergunta o que poderia dar errado: imagem gerada do item errado, hash registrado incorretamente, imagem guardada no compartilhamento errado. Cada modo de falha recebe um método de detecção e uma mitigação, listados numa tabela simples revisada com os peritos, que acrescentam dois modos de falha que ela não tinha visto.
Exemplo resolvido
Priya desenha o fluxo de Northfield e descobre que a passagem da geração de imagem para o exame usa planilhas enviadas por e-mail. Ela define um registro estruturado (ID do item, caminho da imagem, SHA-256, versão da ferramenta, perito, horário) e uma verificação que bloqueia o exame até que o hash seja verificado.
Caso sintético. O fluxo é inventado.
Erros e limites
Um diagrama de sistema simplifica; percorra o processo real com a equipe antes de confiar nele.
Exercícios
- EX046 — Campos da interface. Liste os campos do registro de passagem da geração de imagem para o exame. Rubrica: 3 = ID do item, caminho, SHA-256, versão da ferramenta, perito, horário; 2 = quatro; 1 = dois; 0 = nada.
- EX047 — Rastreabilidade. O que uma matriz de rastreabilidade liga? Rubrica: 3 = requisito, elemento de projeto, teste; 2 = dois; 1 = um; 0 = nada.
- EX048 — Padrão seguro. Dê um exemplo de como tornar fácil a ação segura. Rubrica: 3 = verificação como etapa padrão/bloqueante; 2 = vago; 1 = só treinamento; 0 = nada.
Síntese
Trate o laboratório como um sistema com interfaces definidas, requisitos rastreados, compromissos registrados e padrões seguros.
Continue estudando — capítulo 16 de 50
← Capítulo 15 (rascunho) · Índice de capítulos do curso · Capítulo 17 (rascunho) →