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

Capítulo 40 — Laboratório de verificação II

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 40 — Laboratório de verificação II

Mapa da aula

Aula 40 publicada. Mapa, exemplo, EX118.

flowchart TD
  N0["40.1 Escopo da campanha"]
  N1["40.2 Casos adversariais"]
  N2["40.3 Resultados"]
  N3["40.4 Triagem"]
  N4["40.5 Novo teste"]
  N5["40.6 Decisão de liberação"]
  N6["40.7 Registro"]
  N7["40.8 Lições"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
  N7 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX118"]

Desenho lógico

flowchart LR
  N0["40.1 Escopo da campanha"]
  N1["40.2 Casos adversariais"]
  N2["40.3 Resultados"]
  N3["40.4 Triagem"]
  N4["40.5 Novo teste"]
  N5["40.6 Decisão de liberação"]
  N6["40.7 Registro"]
  N7["40.8 Lições"]
  N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX118"]

[40.1 Escopo da campanha]
    |
    v
[40.2 Casos adversariais]
    |
    v
[40.3 Resultados]
    |
    v
[40.4 Triagem]
    |
    v
[40.5 Novo teste]
    |
    v
[40.6 Decisão de liberação]
    |
    v
[40.7 Registro]
    |
    v
[40.8 Lições]
    |
    v
[Exemplo resolvido] --> [Exercício EX118]

Objetivos de aprendizagem

Você vai (1) executar uma campanha completa de verificação do EvidenceDesk; (2) incluir casos de teste adversariais; (3) registrar e triar defeitos; (4) decidir se o sistema está pronto para a liberação.

40.1 Escopo da campanha

Todos os requisitos FR1–FR5 e NFR1–NFR4, mais os cenários da análise de ameaças e falhas: entradas editadas, entradas apagadas, entradas reordenadas, cadeias reconstruídas, imagens truncadas, escolha da cópia errada e desvio de relógio. Os cenários vêm das análises anteriores de falhas e ameaças, então cada um remonta a um risco que alguém identificou no papel. O desvio de relógio, por exemplo, testa se entradas vindas de uma máquina com o relógio errado são apanhadas pelas verificações de ordenação. As imagens truncadas testam se a verificação percebe um arquivo mais curto do que o registrado. A lista completa é escrita antes do início dos testes.

40.2 Casos adversariais

Um colega de turma que não construiu o sistema faz o papel de um funcionário interno descuidado ou desonesto, sobre dados sintéticos: edita arquivos diretamente, apaga linhas de log, troca imagens com nomes parecidos. Toda tentativa deve ser impedida ou detectada. Quem constrói evita, sem perceber, os caminhos que sabe que são fracos. O colega recebe acesso de administrador ao servidor de testes e uma lista de objetivos, como apagar os vestígios de um erro, mas nenhuma pista sobre as defesas. Ele anota cada tentativa, inclusive as que abandonou, e essas anotações mostram onde o projeto do sistema desestimulou a adulteração.

40.3 Resultados

Dos 46 casos de teste, 44 passam. Dois falham: apagar a última entrada de custódia passa despercebido até a âncora seguinte, e a exportação de um caso com zero itens trava. A primeira falha expõe uma lacuna real: a verificação confere a cadeia até a última âncora, então uma entrada acrescentada depois dessa âncora e em seguida removida não deixa rastro. A segunda é um caso-limite que ninguém tinha testado porque nenhum caso real tem zero itens, embora um possa existir depois de um erro de entrada. As duas são registradas como defeitos, com os passos para reproduzi-las.

40.4 Triagem

A lacuna de exclusão tem severidade alta: uma entrada final poderia sumir por até um dia. Correção: ancorar depois de cada entrada, em vez de diariamente. O travamento tem severidade baixa, mas também é corrigido. A severidade reflete a consequência: perder uma entrada de custódia mina a completude do registro, que é a finalidade central do sistema. Ancorar depois de cada entrada acrescenta uma pequena gravação a cada vez, o que os testes de desempenho mostram ser desprezível. O travamento afeta apenas um caso incomum e não perde dados, mas deixar um travamento conhecido numa ferramenta de evidências convidaria à dúvida, então ele é corrigido na mesma versão.

40.5 Novo teste

Depois das correções, a campanha completa roda de novo; os 46 casos passam. Testes de regressão para os dois defeitos entram no conjunto. Rodar tudo de novo, e não só os dois casos que falharam, protege contra uma correção que quebre outra coisa. Os testes de regressão codificam cada defeito com precisão: apagar a entrada final e esperar a detecção; exportar um caso vazio e esperar um relatório válido e vazio. Eles agora rodam em toda construção futura, então as mesmas falhas não podem voltar em silêncio. A segunda rodada usa os mesmos dados sintéticos e o mesmo testador, de modo que a única coisa que mudou é o próprio código.

40.6 Decisão de liberação

Critérios: todos os requisitos Must passam, nenhum defeito de severidade alta em aberto, registros de validação completos. Atendidos; a versão 1.5.0 é aprovada para o piloto. A aprovação para o piloto é mais estreita que o uso pleno: o EvidenceDesk vai rodar em duas bancadas por três meses ao lado do processo em papel existente. Se os dois discordarem, prevalece o registro em papel e a discrepância é investigada. Os critérios e a decisão são escritos antes da liberação, para que a escolha de colocar em produção não possa ser feita só por entusiasmo. Um critério não atendido teria significado corrigir e testar de novo primeiro, por mais perto que estivesse o prazo.

40.7 Registro

O relatório da campanha lista os casos, os resultados, os defeitos, as correções e a decisão de liberação, assinado por Priya e pelo revisor. O relatório assinado é o documento que um tribunal ou um acreditador pediria para ver. Cada caso de teste tem um identificador, o resultado esperado, o resultado obtido e a data. Os defeitos apontam para os commits de correção e os testes de regressão. A assinatura do revisor mostra que alguém além de quem construiu o sistema conferiu os resultados antes da decisão de liberação. Cópias vão para o gerente da qualidade e para a pasta da versão, onde ficam ao lado do relatório de validação.

40.8 Lições

Testadores adversariais encontram problemas que quem constrói não vê. Os dois defeitos foram encontrados pelo colega, e não pelos testes da própria Priya, e ambos estavam em caminhos que ela supunha que ninguém tomaria. Ela anota, para projetos futuros, que uma rodada adversarial deve ser planejada cedo, e não acoplada no fim, e que os testadores devem incluir alguém sem interesse em que o projeto pareça bom. Hugo acrescenta que o mesmo vale para os procedimentos do laboratório. Priya também registra quais das suas próprias suposições o colega derrubou, para que a análise de ameaças possa ser atualizada.

Gestão dos dados de teste

Os casos de teste sintéticos ficam numa pasta versionada com um manifesto de hashes, para que a campanha sempre rode sobre as mesmas entradas. Quando um caso novo é acrescentado, o manifesto é atualizado e revisado como código, mantendo os resultados das campanhas antigas comparáveis.

Exemplo resolvido

O testador apaga a última linha do log de custódia. Antes da correção, a cadeia restante confere e coincide com a âncora do dia anterior, então nada é sinalizado. Depois da ancoragem por entrada, a exclusão é detectada de imediato, porque a âncora mais recente nomeia um elo que não existe mais.

Caso sintético. A campanha é inventada.

Erros e limites

Uma campanha aprovada cobre os casos imaginados; cenários novos precisam de testes novos.

Exercícios

Síntese

Campanhas completas com testadores adversariais, triagem honesta e novos testes decidem se o sistema está pronto para a liberação.

Continue estudando — capítulo 40 de 50

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