Definir o que a evidência permite afirmar
O laboratório cria ficheiros sintéticos numa diretoria temporária própria. O objetivo é comparar bytes, identidade observada e registos de transferência, sem investigar um sistema real. Antes da aquisição, atribui um identificador de evidência e regista origem declarada, âmbito autorizado, método e responsável. O manifest do exercício contém tamanho e SHA-256 da cópia. Estes campos permitem verificar alterações relativamente à referência guardada, mas não demonstram sozinhos autenticidade da origem ou completude de um incidente. Dois caminhos podem conter exatamente os mesmos bytes e produzir o mesmo digest. Para a operação, isso significa que a narrativa sobre a origem precisa de evidência adicional e de um processo controlado. Guarda uma cópia de trabalho separada para análise e mantém explícito qual o objeto que cada resultado descreve.
Reconhecer uma cópia inconsistente
No ensaio controlado, a origem contém 4096 bytes A. Depois de a leitura sem buffering obter os primeiros 1024, o próprio script substitui o conteúdo por 4096 bytes B. A cópia termina com 1024 A e 3072 B: mantém o tamanho, mas difere das versões inicial e final. O resultado esperado é rejeitar a afirmação de aquisição estável e conservar a informação sobre a tentativa. Numa primeira execução com buffering, a biblioteca antecipou a leitura e a mistura não apareceu; esse resultado também foi registado. O leitor final usa buffering=0 para tornar a injeção observável no ponto pretendido. Nenhum destes casos prova comportamento de todos os sistemas de ficheiros. Uma leitura antes e depois deteta as alterações introduzidas, mas não cria um snapshot atómico nem exclui alterações transitórias adversariais.
Distinguir caminho, descritor e proteção de escrita
Outro ensaio abre um ficheiro e substitui depois o caminho por um objeto diferente. O descritor aberto continua a ler os bytes antigos, enquanto uma nova consulta ao caminho encontra outra identidade. O laboratório compara identidade e hashes para recusar a conclusão de origem estável naquele percurso. Em seguida aplica modo 0400 à cópia e demonstra que o proprietário pode repor permissão de escrita e alterá-la. A proteção reduz alterações acidentais em certas condições, mas não constitui armazenamento imutável contra esse utilizador. O script chama fsync antes de prosseguir e regista sucesso; não simula perda de energia. Num relatório técnico, separa cada mecanismo da garantia que se pretende obter. Um hash correto, uma permissão restrita e uma chamada concluída respondem a questões diferentes.
Verificar a cadeia e proteger a referência
O modelo regista eventos de transferência ligados pelo digest anterior. Alterar um ator, remover uma entrada intermédia ou trocar a ordem quebra a verificação contra a referência final original. Retirar a última entrada também é detetado quando essa referência é conservada. Depois, o exercício dá ao mesmo utilizador capacidade para reescrever todos os registos e substituir a referência. A cadeia forjada passa contra essa nova referência, expondo uma fronteira de confiança inadequada. Isso não é uma colisão SHA-256. O modelo apenas calcula novamente dados controlados pelo utilizador. Um desenho operacional precisa de definir quem pode escrever, quem guarda a referência, como se autenticam eventos e quais os requisitos de retenção. O laboratório não fornece timestamps de confiança, testemunho independente ou armazenamento WORM.
Executar e explicar os resultados do laboratório
Executa o script com Python 3.13.1 ou um ambiente compatível, guarda o JSON num local próprio e lê os resultados antes de tirar conclusões. As duas execuções registadas têm 25 verificações cada: aquisição estável, alteração durante leitura, substituição de caminho, igualdade de bytes, permissões, cadeia de registos e limpeza. Prevê quais as verificações que recusam dados alterados e quais expõem uma proteção insuficiente. Confirma que a origem sintética fica intacta no teste estável e que a diretoria temporária é removida. Compara o SHA-256 do script com o valor registado para ligar evidência e versão executada. Todos os dados pertencem ao exercício. Não apontes este script a logs de produção nem o apresentes como ferramenta de recolha forense; o objetivo é explicar mecanismos limitados através de observações reproduzíveis.
Relatar um resultado incompleto sem o esconder
O caso final impõe um prazo de vinte minutos para entregar evidência. A cópia tem o tamanho esperado, mas os hashes da origem inicial, da cópia e da origem final diferem. Preserva os resultados e classifica a tentativa como inconsistente. Avalia uma nova aquisição autorizada sobre uma origem estabilizada ou mecanismo apropriado, com apoio especializado quando necessário. Não substituas o hash da referência pelo da cópia para fazer a comparação passar nem concluas que a diferença prova ataque. No relatório, indica observação, limitação, consequência para a análise e próximo passo. A pressão temporal justifica escalada e decisão sobre o prazo, sem alterar os factos. Resume a lição: integridade relativa aos bytes, identidade observada, proveniência e autorização precisam de evidência própria; nenhum único campo do manifest demonstra todas estas propriedades.
python3 content/labs/securityx-operations-contracts/run.py --output /tmp/securityx-operations-evidence.json
# Inspect passed/failed, changedDuringAcquisition and pathReplacement.
# Synthetic ordinary files only; no production paths are accepted.
# Actual recorded runtime: Python 3.13.1. No forensic imaging or trusted custody service.Uma cópia de 4096 bytes mistura duas versões e mantém o tamanho. Os três hashes diferentes impedem declarar a aquisição estável.
Armadilhas comuns
Tratar hash como proveniência, modo 0400 como WORM, cadeia editável como testemunho independente ou tamanho igual como cópia estável.
Tópicos relacionados: Resposta e recuperação · Telemetria e qualidade da deteção · Governance e risco
Liga cada conclusão ao objeto e mecanismo realmente verificados, preservando resultados que limitam a interpretação.
Referência: Guide to Integrating Forensic Techniques into Incident Response · CAS-005 / SecurityX V5; objectives 3.0; launched 2024-12-17