Capítulo 23 — Perícia digital e análise de malware: análise de ameaças e de falhas
Mapa da aula
Aula 23 publicada. Mapa, exemplo, EX067.
flowchart TD
N0["23.1 Análise de ameaças"]
N1["23.2 Modos de falha"]
N2["23.3 Classificação"]
N3["23.4 Mitigações"]
N4["23.5 Risco residual"]
N5["23.6 Malware nas evidências"]
N6["23.7 Cadência de revisão"]
N7["Cadeia de suprimentos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX067"]
Desenho lógico
flowchart LR
N0["23.1 Análise de ameaças"]
N1["23.2 Modos de falha"]
N2["23.3 Classificação"]
N3["23.4 Mitigações"]
N4["23.5 Risco residual"]
N5["23.6 Malware nas evidências"]
N6["23.7 Cadência de revisão"]
N7["Cadeia de suprimentos"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX067"]
[23.1 Análise de ameaças]
|
v
[23.2 Modos de falha]
|
v
[23.3 Classificação]
|
v
[23.4 Mitigações]
|
v
[23.5 Risco residual]
|
v
[23.6 Malware nas evidências]
|
v
[23.7 Cadência de revisão]
|
v
[Cadeia de suprimentos]
|
v
[Exemplo resolvido] --> [Exercício EX067]
Objetivos de aprendizagem
Você vai (1) identificar ameaças a um sistema de evidências; (2) realizar uma análise de modos de falha e seus efeitos; (3) classificar riscos; (4) escolher mitigações.
23.1 Análise de ameaças
Quem poderia querer alterar os registros das evidências? Uma parte num caso, alguém de dentro encobrindo um erro, um ransomware. O que poderiam ter como alvo? Logs de custódia, digests, imagens. Priya lista as ameaças com o ativo, o agente e o impacto. O impacto depende do que o atacante ganha. Uma parte num caso que altere um digest pode lançar dúvida sobre um anexo de prova. Alguém de dentro que reescreva entradas de custódia pode esconder um item perdido. Um ransomware que cifre os registros pode parar totalmente o trabalho com os casos. Cada linha de ameaça também anota o que hoje a detectaria, o que muitas vezes é nada, e essas linhas viram prioridades de projeto.
23.2 Modos de falha
Nem todo risco é malicioso. A FMEA lista cada componente, como ele poderia falhar, o efeito e como a falha seria detectada. Exemplo: o disco enche durante a geração da imagem → imagem truncada → detectada pela verificação de tamanho e pela divergência de hash. Outro exemplo: o relógio do servidor se desvia depois de uma atualização de firmware. O efeito são eventos de custódia com horários errados, detectados ao comparar o servidor com a fonte de tempo de referência na verificação diária. Um terceiro: uma impressora de etiquetas borra um código de barras, de modo que a leitura falha ou lê o item errado. O dígito verificador detecta isso. Cada linha termina dizendo se a detecção é automática ou depende de alguém perceber.
23.3 Classificação
Cada falha recebe notas de severidade, probabilidade e detectabilidade; o produto delas ordena as prioridades. Uma falha severa e difícil de detectar fica no topo. Numa escala de um a cinco para cada fator, a corrupção silenciosa de uma imagem arquivada poderia receber severidade 5, probabilidade 2 e detectabilidade 5 (difícil de detectar), o que dá 50. Uma etiqueta borrada recebe nota menor porque o dígito verificador a pega. Priya usa a classificação para decidir o esforço de teste, e também anota que as notas são julgamentos, por isso dois revisores pontuam de forma independente e discutem as diferenças.
23.4 Mitigações
Cadeia de hashes no log de custódia (detecta edições); armazenamento de gravação única (impede sobrescrita); verificação de espaço em disco antes da geração da imagem (impede truncamento); backups offline (restauram depois de um ransomware). Cada mitigação é rastreada para trás, até as ameaças ou falhas de que trata, e para a frente, até um teste. O armazenamento de gravação única, por exemplo, é testado tentando sobrescrever um registro armazenado com uma conta privilegiada e esperando uma recusa. Quando uma mitigação apenas detecta, em vez de impedir, a resposta também é escrita: quem é alertado e o que faz primeiro.
23.5 Risco residual
Algum risco permanece: alguém de dentro, corrupto e com acesso total, poderia fabricar um histórico inteiro novo antes que alguém percebesse. A segregação de funções e a revisão externa periódica o reduzem. A segregação de funções significa que fabricar um histórico exigiria conluio, porque as correções precisam de um segundo aprovador. A revisão externa periódica compara os registros do EvidenceDesk com as etiquetas físicas, os logs de armazenamento e os logs das estações de geração de imagens, que uma única pessoa de dentro não consegue controlar ao mesmo tempo. O risco residual é registrado com a assinatura da gerente do laboratório, o que torna sua aceitação uma decisão deliberada, e não um descuido.
23.6 Malware nas evidências
As evidências podem conter malware. O EvidenceDesk nunca abre o conteúdo das evidências; apenas calcula o hash dos bytes. O cálculo do hash lê os bytes como dados e nunca os executa, então um arquivo malicioso numa imagem é inofensivo para o verificador. O risco vem de recursos que poderiam interpretar o conteúdo, como pré-visualizações ou extração de metadados. Priya exclui esses recursos do EvidenceDesk por projeto. Qualquer proposta posterior de acrescentá-los precisaria de sua própria análise de ameaças e funcionaria na zona de análise isolada. Os arquivos são abertos como fluxos de bytes brutos, sem associações de arquivo.
23.7 Cadência de revisão
A análise é revista quando os componentes mudam ou ocorre um incidente. Os gatilhos incluem uma nova plataforma de armazenamento, uma mudança em quem administra o servidor, um defeito relatado com implicações para a integridade ou um incidente em outro laboratório que use ferramentas semelhantes. Cada revisão registra a data, os participantes, as ameaças acrescentadas ou removidas e as mudanças na classificação. Uma análise que não muda depois de uma revisão não é problema, desde que a revisão mostre que ela foi de fato considerada. Sem um gatilho agendado, as revisões tendem a acontecer só depois de um incidente, que é o pior momento para descobrir que uma premissa ficou desatualizada.
Cadeia de suprimentos
O EvidenceDesk depende do próprio Python e do sistema operacional. Priya registra as versões, obtém o Python da fonte oficial com os checksums publicados e planeja como uma vulnerabilidade em qualquer um dos dois seria avaliada. Como o código usa apenas a biblioteca padrão, não há pacotes de terceiros cujo comprometimento possa alterar os registros.
Exemplo resolvido
A falha mais bem classificada: um perito verifica a cópia errada porque os nomes dos arquivos são parecidos. Severidade alta, detectabilidade baixa. Mitigação: o EvidenceDesk verifica pelo ID do item e pelo caminho armazenado, não pelo nome digitado pelo usuário.
Caso sintético. As notas são inventadas.
Erros e limites
As notas são julgamentos; registre quem pontuou e por quê.
Exercícios
- EX067 — Disco cheio. Qual é o efeito e qual é a detecção de um disco cheio durante a geração da imagem? Rubrica: 3 = imagem truncada; verificação de tamanho e divergência de hash; 2 = um; 1 = vago; 0 = nada.
- EX068 — Lógica da classificação. Por que uma falha severa e difícil de detectar fica no topo? Rubrica: 3 = grande dano e provavelmente passa despercebida; 2 = parcial; 1 = aleatório; 0 = nada.
- EX069 — Cópia errada. Como o EvidenceDesk evita a verificação da cópia errada? Rubrica: 3 = verifica pelo ID do item e pelo caminho armazenado; 2 = parcial; 1 = treinamento; 0 = nada.
Síntese
A análise de ameaças e a FMEA, juntas, mostram onde o EvidenceDesk precisa detectar, impedir ou recuperar.
Continue estudando — capítulo 23 de 50
← Capítulo 22 (rascunho) · Índice de capítulos do curso · Capítulo 24 (rascunho) →