Capítulo 4 — Replicação das linhas de base e piloto
Mapa da aula
Aula 04 publicada. Mapa, exemplo, EX021.
flowchart TD
N0["4.1 Termos"]
N1["4.2 Diagnosticar uma reprodução fracassada: InvBench"]
N2["4.3 Verificar o instrumento"]
N3["4.4 Atividade prática — Laboratório 4: verificar o c"]
N4["4.5 Ajustar sem vazamento"]
N5["4.6 Um piloto delimitado"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX021"]
Desenho lógico
flowchart LR
N0["4.1 Termos"]
N1["4.2 Diagnosticar uma reprodução fracassada: InvBench"]
N2["4.3 Verificar o instrumento"]
N3["4.4 Atividade prática — Laboratório 4: verificar o c"]
N4["4.5 Ajustar sem vazamento"]
N5["4.6 Um piloto delimitado"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX021"]
[4.1 Termos]
|
v
[4.2 Diagnosticar uma reprodução fracassada: InvBench]
|
v
[4.3 Verificar o instrumento]
|
v
[4.4 Atividade prática — Laboratório 4: verificar o c]
|
v
[4.5 Ajustar sem vazamento]
|
v
[4.6 Um piloto delimitado]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX021]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você consegue (1) distinguir repetibilidade, reprodutibilidade e replicabilidade; (2) diagnosticar por que um resultado de inventário publicado não se reproduz; (3) verificar um instrumento com entradas conhecidas antes de confiar na sua saída; (4) ajustar parâmetros sem vazar dados de teste; e (5) executar um piloto delimitado que termine numa decisão explícita de seguir ou não seguir. Ele aplica a proposta do Capítulo 3 antes do estudo principal do Capítulo 5.
4.1 Termos
Seguindo o vocabulário de revisão e selos de artefatos da ACM: repetibilidade — a mesma equipe obtém o mesmo resultado com a mesma configuração; reprodutibilidade — uma equipe diferente o obtém com os artefatos originais; replicabilidade — uma equipe diferente o obtém com artefatos desenvolvidos de forma independente. Uma linha de base de doutorado deve ser pelo menos reproduzida, e o registro da reprodução deve anotar cada desvio, incluindo as versões dos scanners, dos analisadores e do registro de grupos TLS usado para classificar os codepoints.
No Ciphertrail Study, o trabalho sobre o InvBench-22 é uma reprodução, porque reutiliza o corpus divulgado.
4.2 Diagnosticar uma reprodução fracassada: InvBench-22
O artigo sintético InvBench-22 relata que o seu scanner encontrou "97% dos ativos vulneráveis à computação quântica". O candidato obtém o corpus divulgado e chega a 61%. Surgem três causas, na ordem em que foram descobertas. Primeiro, contagem duplicada: o artigo contou constatações, não usos — o mesmo servidor aparecia com um nome curto, um nome totalmente qualificado e dois endereços IP, cada um contado como acerto contra um único item da verdade de referência. Segundo, vazamento da verdade de referência: a verdade de referência foi montada em parte a partir da saída anterior do próprio scanner, então os itens que o scanner não conseguia ver faltavam no denominador. Terceiro, deriva do registro: o classificador do artigo era anterior aos codepoints finais do ML-KEM e rotulava o codepoint híbrido pré-padrão obsoleto como "desconhecido", que os autores depois excluíram. Nada disso é fraude; cada uma é uma decisão de medição que não foi relatada. O registro da reprodução enuncia cada causa, quantifica o seu efeito e anota quais são inferências, e não fatos confirmados pelos autores.
4.3 Verificar o instrumento
Antes de medir a HRHN, verifique se o classificador passivo mapeia corretamente cada codepoint de grupo suportado do TLS. O registro de Grupos Suportados do TLS da IANA lista os codepoints; a RFC 10024 define o X25519MLKEM768, o SecP256r1MLKEM768 e o SecP384r1MLKEM1024. Testes unitários com entradas conhecidas são a evidência de validade mais barata que uma tese pode ter. Duas regras de desenho importam. Um codepoint desconhecido precisa ser classificado como desconhecido, nunca como seguro. E a identidade precisa ser canonizada antes da contagem, para que um uso seja uma linha.
4.4 Atividade prática — Laboratório 4: verificar o classificador e contar usos
# Lab 4 (synthetic): verify the passive classifier and show how duplicate counting inflates recall.
# TLS supported-group codepoints (IANA registry): 0x001D x25519, 0x0017 secp256r1,
# 0x11EC X25519MLKEM768, 0x11EB SecP256r1MLKEM768, 0x11ED SecP384r1MLKEM1024,
# 0x6399 X25519Kyber768Draft00 (obsolete pre-standard codepoint).
GROUPS = {0x001D: "classical", 0x0017: "classical", 0x11EC: "hybrid", 0x11EB: "hybrid",
0x11ED: "hybrid", 0x6399: "pre-standard hybrid"}
def classify(code):
return GROUPS.get(code, "unknown") # never default an unknown codepoint to "safe"
tests = [(0x001D, "classical"), (0x11EC, "hybrid"), (0x6399, "pre-standard hybrid"), (0xFFFF, "unknown")]
assert all(classify(c) == want for c, want in tests), "classifier unit test failed"
print("classifier unit tests: 4/4 pass")
# Synthetic handshake findings: (server pseudonym, port, selected group)
findings = [("srv-014", 443, 0x001D), ("srv-014", 443, 0x001D), ("SRV-014.halden.example", 443, 0x001D),
("srv-022", 8443, 0x11EC), ("srv-031", 443, 0x0017), ("srv-031", 443, 0x0017)]
truth_vulnerable = {("srv-014", 443), ("srv-031", 443), ("srv-040", 22)} # adjudicated uses
def canon(host):
return host.lower().split(".")[0]
raw_hits = sum(1 for h, p, g in findings if classify(g) == "classical")
uses = {(canon(h), p) for h, p, g in findings if classify(g) == "classical"}
print(f"raw classical findings: {raw_hits} -> naive 'recall' {raw_hits}/{len(truth_vulnerable)} = {raw_hits/len(truth_vulnerable):.2f}")
print(f"canonical uses found: {len(uses & truth_vulnerable)} -> recall {len(uses & truth_vulnerable)/len(truth_vulnerable):.2f}")
Saída esperada:
classifier unit tests: 4/4 pass
raw classical findings: 5 -> naive 'recall' 5/3 = 1.67
canonical uses found: 2 -> recall 0.67
Uma "revocação" acima de 1 é o sinal mais claro possível de um erro de unidade, mas uma inflação mais sutil — digamos, de 0,61 para 0,97 — parece plausível e sobrevive à revisão, a menos que a unidade de contagem seja declarada. O uso de SSH ausente em srv-040 também ilustra o modelo de observador: o sensor de TLS não consegue encontrá-lo.
O laboratório separa duas verificações fáceis de confundir. Os testes unitários mostram que o classificador mapeia corretamente os codepoints conhecidos, incluindo um desconhecido. A etapa de contagem mostra como o mesmo servidor, registrado repetidas vezes e com dois nomes, pode inflar a revocação. Mantenha as duas no conjunto de testes do instrumento e execute-as antes de cada coleta, registrando a data de obtenção do registro da IANA ao lado dos resultados.
4.5 Ajustar sem vazamento
A regra de fusão tem parâmetros: por quanto tempo uma observação passiva continua válida, como os nomes de host são associados aos repositórios de código e o limiar de confiança para atribuir um grupo negociado a um ativo. Ajuste-os numa partição de desenvolvimento (no Ciphertrail Study, o hospital 1 da HRHN), congele-os e avalie nos hospitais 2 e 3, reservados. Registre cada execução de ajuste, inclusive as abandonadas; um jardim de caminhos que se bifurcam que fica escondido é indistinguível de p-hacking.
Mantenha um registro de ajustes com a data, os valores dos parâmetros e o resultado no hospital 1 para cada execução. Quando as regras forem congeladas, registre o hash da configuração no mesmo registro.
4.6 Um piloto delimitado
O piloto dura duas semanas num segmento da HRHN com 140 serviços. Critérios de seguir/não seguir declarados de antemão: todos os testes unitários do classificador passam; a pseudonimização é verificada numa amostra de 200 registros por uma segunda pessoa; nenhum incidente operacional atribuível ao estudo; concordância entre adjudicadores (κ de Cohen) de pelo menos 0,70 num conjunto de calibração de 60 itens; e o protocolo não exige mais de quatro horas de engenheiro por 100 serviços. O piloto sintético atende a quatro critérios, mas registra κ = 0,62, porque os adjudicadores discordaram sobre se um conjunto de cifras de troca de chaves RSA configurado, mas nunca negociado, é um "uso". A decisão é seguir com emenda: o livro de códigos agora define um uso como qualquer algoritmo alcançável por um par na negociação, com uma marcação separada para "configurado, não observado".
4.7 Erros comuns e limites
- Contar constatações em vez de usos; declare sempre a unidade.
- Montar a verdade de referência a partir da ferramenta em teste.
- Usar um registro de codepoints desatualizado; registre a data de obtenção.
- Ajustar com dados de teste, mesmo informalmente, "olhando alguns resultados".
- Um piloto sem critérios declarados de antemão não pode falhar e, portanto, ensina pouco.
Cada erro tem uma salvaguarda neste estudo: identificadores canônicos para os usos, adjudicação cega em relação à ferramenta, um registro datado, uma partição por hospital com regras congeladas e critérios do piloto declarados de antemão. A baixa concordância de 0,62 do piloto é um exemplo de critério fazendo o seu trabalho; ela forçou uma emenda ao livro de códigos antes do estudo principal, e não depois.
Exercícios — capítulo 4
- EX021 — Vocabulário. Classifique três cenários como repetibilidade, reprodutibilidade ou replicabilidade. Rubrica: 3 = todos corretos, com uma justificativa de uma linha cada.
- EX022 — Registro da reprodução. Escreva o item do registro para a causa 2 do InvBench-22, separando observação de inferência. Rubrica: 3 = efeito quantificado, inferência rotulada.
- EX023 — Estender o classificador. Acrescente ao Laboratório 4 testes unitários para o SecP384r1MLKEM1024 (0x11ED, já presente na tabela) e para um codepoint desconhecido 0x0200. Rubrica: 3 = os testes passam e o desconhecido continua desconhecido.
- EX024 — Identidade canônica. Proponha uma regra de canonização de um uso que trate endereços IP, apelidos e balanceadores de carga. Rubrica: 3 = aborda pelo menos um modo de falha da regra.
- EX025 — Desenho da partição. Projete partições de desenvolvimento/teste para a HRHN que evitem vazamento quando dois hospitais compartilham uma PKI. Rubrica: 3 = identifica o vazamento pela PKI compartilhada e o mitiga.
- EX026 — Seguir/não seguir. Dado κ = 0,62 e todos os outros critérios atendidos, escreva o memorando de decisão. Rubrica: 3 = decisão justificada, emenda específica, critério de novo teste enunciado.
Síntese do capítulo
As linhas de base são reproduzidas antes de serem superadas; os instrumentos são verificados com entradas conhecidas; a unidade de contagem é declarada; o ajuste é separado do teste; e um piloto existe para poder falhar. A revocação inflada do InvBench-22 veio de três decisões de medição não relatadas, e não do scanner.
Continue estudando — capítulo 04 de 08
← Capítulo 03 · Índice de capítulos do curso · Capítulo 05 →
Siga para a próxima lição escrita.