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

Capítulo 37 — Perícia digital e análise de *malware*: operações

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 37 — Perícia digital e análise de malware: operações

Mapa da aula

Aula 37 publicada. Mapa, exemplo, EX109.

flowchart TD
  N0["37.1 Procedimentos operacionais padrão"]
  N1["37.2 Papéis"]
  N2["37.3 Verificações diárias"]
  N3["37.4 Passagem de trabalho"]
  N4["37.5 Incidentes no sistema"]
  N5["37.6 Janelas de mudança"]
  N6["37.7 Treinamento"]
  N7["Métricas na operação"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX109"]

Desenho lógico

flowchart LR
  N0["37.1 Procedimentos operacionais padrão"]
  N1["37.2 Papéis"]
  N2["37.3 Verificações diárias"]
  N3["37.4 Passagem de trabalho"]
  N4["37.5 Incidentes no sistema"]
  N5["37.6 Janelas de mudança"]
  N6["37.7 Treinamento"]
  N7["Métricas na operação"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX109"]

[37.1 Procedimentos operacionais padrão]
    |
    v
[37.2 Papéis]
    |
    v
[37.3 Verificações diárias]
    |
    v
[37.4 Passagem de trabalho]
    |
    v
[37.5 Incidentes no sistema]
    |
    v
[37.6 Janelas de mudança]
    |
    v
[37.7 Treinamento]
    |
    v
[Métricas na operação]
    |
    v
[Exemplo resolvido] --> [Exercício EX109]

Objetivos de aprendizagem

Você vai (1) escrever procedimentos operacionais para o EvidenceDesk; (2) definir papéis e passagens de trabalho; (3) monitorar a operação diária; (4) tratar incidentes no sistema de evidências.

37.1 Procedimentos operacionais padrão

Procedimentos curtos e numerados: entrada, registro de aquisição, verificação, exportação, correção, exceção. Cada um declara a finalidade, o papel responsável, os passos, os registros produzidos e o que fazer se algo falhar. O SWGDE publica procedimentos-modelo e documentos de boas práticas que Priya usa como referência estrutural. A numeração importa porque um tribunal pode perguntar exatamente qual passo foi seguido, e "o passo 4 do procedimento de verificação" é muito mais fácil de apontar do que um parágrafo de texto corrido. Cada procedimento cabe em duas páginas, então ele é de fato lido na bancada. O número da versão e a data de vigência ficam no cabeçalho, e o EvidenceDesk registra qual versão estava em vigor quando cada ação foi realizada.

37.2 Papéis

Atendente de entrada, perito, revisor, administrador, gerente da qualidade. Uma matriz de papéis mostra quem pode fazer o quê. Na matriz, os atendentes de entrada criam itens e registram recebimentos, mas não podem marcar uma verificação como concluída; os peritos verificam e examinam, mas não podem aprovar as próprias correções; os revisores aprovam correções, mas não podem apagar nada; os administradores mantêm o servidor, mas não têm nenhuma permissão no nível dos casos. O gerente da qualidade pode ler tudo e aprovar mudanças nos procedimentos. O EvidenceDesk impõe a matriz no código, e o conjunto de testes confere uma ação proibida para cada papel.

37.3 Verificações diárias

Resultado da verificação da cadeia, conclusão do backup, situação da fila, espaço em disco. O gerente da qualidade assina a folha de verificação diária. Cada item tem uma condição clara de aprovação: a cadeia confere até a âncora mais recente, o backup da noite anterior terminou com hashes coincidentes, nenhuma tarefa ficou na fila por mais de um dia e o espaço livre em disco passa de vinte por cento. Qualquer falha é anotada na folha com a providência tomada. Uma sequência de folhas assinadas mostra a um auditor que as verificações aconteceram todos os dias, e não apenas antes das inspeções.

37.4 Passagem de trabalho

Quando um perito passa um caso a outro, o EvidenceDesk registra a transferência, e o perito que recebe verifica as cópias de trabalho antes de continuar. As passagens acontecem quando um perito sai de licença, muda de função ou é designado para um caso mais urgente. O perito que recebe recalcula o hash de cada cópia de trabalho e o compara com o valor registrado antes de confiar em qualquer anotação anterior. Isso protege as duas pessoas: quem sai pode mostrar em que estado deixou o trabalho, e quem entra não é culpado por problemas que já existiam antes de assumir.

37.5 Incidentes no sistema

Uma falha na verificação da cadeia é um incidente de qualidade: interrompa o trabalho dependente, preserve os logs, investigue, corrija pelo caminho adequado e comunique ao gerente da qualidade. Interromper o trabalho dependente impede que novos exames se apoiem em registros que podem estar errados. Preservar os logs vem antes de qualquer reparo, porque consertar primeiro pode destruir as pistas sobre o que aconteceu. A investigação pode encontrar uma falha de disco, um bug ou uma edição deliberada. Qualquer que seja a causa, a correção passa pela entrada de correção normal, nunca por uma edição direta do arquivo, e os casos afetados são listados para o gerente da qualidade.

37.6 Janelas de mudança

As atualizações acontecem fora do horário de exames, depois de um backup, e são seguidas pelos testes com vetores. Rodar atualizações durante o horário de exames arrisca que uma versão instalada pela metade grave registros, ou que um perito perca trabalho quando o serviço reinicia. O backup feito logo antes oferece um ponto conhecido para onde voltar se a atualização falhar. Rodar os testes com vetores logo em seguida confirma que o cálculo dos hashes ainda coincide com os valores publicados. Cada atualização, com sua versão, horário e resultado dos testes, é lançada no log de mudanças pelo administrador.

37.7 Treinamento

Os novos funcionários executam os procedimentos com itens sintéticos antes de lidar com itens reais. Os itens sintéticos se parecem com os reais, com etiquetas, sacos e pequenas imagens de disco, mas não contêm nada sensível e não pertencem a nenhum caso. Os treinandos executam cada procedimento de ponta a ponta, incluindo falhas provocadas de propósito, como uma divergência de hash, para que o primeiro contato com um erro não seja com evidência real. Um supervisor dá o aceite em cada procedimento, e o EvidenceDesk só concede o papel depois que o treinamento é registrado. Sessões de reciclagem acompanham qualquer mudança de procedimento.

Métricas na operação

Todo mês, o painel de Priya relata entradas, aquisições, falhas de verificação, exceções usadas e resultados dos testes de restauração. Uma contagem de exceções em alta leva a revisar se um controle está incômodo demais. Os números são discutidos na reunião da qualidade e registrados em ata, de modo que as tendências ficam visíveis ao longo dos anos e as mudanças podem ser julgadas pelo seu efeito.

Exemplo resolvido

Na segunda-feira, a verificação da cadeia falha. Os logs mostram que um administrador restaurou um arquivo a partir do backup de sexta-feira durante uma manutenção, perdendo as entradas feitas no fim de semana. As entradas do fim de semana são relançadas a partir dos formulários de contingência em papel e das âncoras, a causa é registrada, e o procedimento de manutenção ganha um passo de "conciliar após restaurar".

Caso sintético. O incidente é inventado.

Erros e limites

Os procedimentos envelhecem; revise-os todo ano e depois de cada incidente.

Exercícios

Síntese

Procedimentos claros, papéis, verificações diárias e tratamento de incidentes mantêm o EvidenceDesk confiável no uso.

Continue estudando — capítulo 37 de 50

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