Capítulo 15 — Evidência e medição
Mapa da aula
Aula 15 publicada. Mapa, exemplo, EX043.
flowchart TD
N0["15.1 Hashes"]
N1["15.2 Métricas"]
N2["15.3 Custódia"]
N3["15.4 Integridade vs verdade"]
N4["15.5 Amostragem"]
N5["15.6 PulseMap"]
N6["15.7 Amostragem aleatória de tickets fechados"]
N7["15.8 Um dicionário para os termos das métricas"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX043"]
Desenho lógico
flowchart LR
N0["15.1 Hashes"]
N1["15.2 Métricas"]
N2["15.3 Custódia"]
N3["15.4 Integridade vs verdade"]
N4["15.5 Amostragem"]
N5["15.6 PulseMap"]
N6["15.7 Amostragem aleatória de tickets fechados"]
N7["15.8 Um dicionário para os termos das métricas"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX043"]
[15.1 Hashes]
|
v
[15.2 Métricas]
|
v
[15.3 Custódia]
|
v
[15.4 Integridade vs verdade]
|
v
[15.5 Amostragem]
|
v
[15.6 PulseMap]
|
v
[15.7 Amostragem aleatória de tickets fechados]
|
v
[15.8 Um dicionário para os termos das métricas]
|
v
[Exemplo resolvido] --> [Exercício EX043]
Objetivos de aprendizagem
Você vai (1) calcular hashes de evidências; (2) escolher métricas que não sejam de vaidade; (3) manter a cadeia de custódia.
15.1 Hashes
Detectar edições acidentais antes do registro. Um hash criptográfico como o SHA-256 transforma um arquivo numa impressão digital curta que muda completamente se até um único byte mudar. Sam calcula o hash de cada arquivo de evidência quando o captura e de novo quando o anexa a um achado. Se os valores diferem, algo tocou o arquivo nesse meio-tempo, talvez um editor de imagens que o salvou de novo, uma ferramenta de sincronização que converteu as quebras de linha ou uma redação descuidada sobre o original. Pegar isso antes de o relatório sair é fácil. Explicar isso depois que um cliente contesta o achado é muito mais difícil, porque um arquivo alterado parece igual a um adulterado.
15.2 Métricas
Ativos tocados, cartões executados, donos designados — não contagens brutas de achados. Uma contagem de achados mede sobretudo o quanto os testadores procuraram e como dividiram os problemas em registros separados. Um aumento de quarenta para sessenta poderia significar que o banco piorou, que o escopo cresceu ou que uma fraqueza foi registrada por host em vez de uma única vez. Medidas mais úteis descrevem o trabalho e seu efeito: quantos ativos do escopo foram de fato testados, quantos métodos de teste planejados foram concluídos, quantos achados têm um dono nomeado e uma data-limite e quanto tempo as correções levam. O PulseMap relata essas medidas, para que um gestor possa saber se um trimestre calmo significa segurança ou pouco teste.
15.3 Custódia
Quem/quando/onde para cada artefato. Um registro de cadeia de custódia lista todo ponto em que a evidência mudou de mãos ou de lugar: capturada por Sam num notebook de testes às 21:14, enviada ao FindingsDesk às 21:20, lida pelo revisor na manhã seguinte, exportada em forma redigida para o relatório. Cada entrada tem uma pessoa, um horário e um lugar. Se um achado for contestado meses depois, o registro mostra que a evidência apresentada é a evidência capturada e quem poderia tê-la alterado. Lacunas são registradas como lacunas. Uma nota honesta de que um arquivo ficou num notebook por dois dias é melhor que um registro que esconde isso.
15.4 Integridade vs verdade
Hash coincidente ≠ sistema vivo ainda vulnerável. Um hash coincidente prova apenas que o arquivo de evidência não mudou desde que foi capturado. Ele não diz nada sobre se a fraqueza ainda existe, se a evidência foi corretamente entendida ou se o teste era válido. Uma captura de tela pode estar perfeitamente preservada e ainda assim mostrar uma leitura errada. Um servidor vulnerável em março pode ter sido corrigido em abril. É por isso que o TRB separa a integridade da evidência, verificada com hashes, do status do achado, verificado por um reteste. As afirmações do relatório são datadas no momento do teste, por exemplo que o endpoint devolveu dados de outro cliente em 4 de março, e não que ele faz isso agora.
15.5 Amostragem
Amostre tickets fechados em busca de evidência de verificação. Conferir todo ticket fechado raramente é viável, e conferir só os que alguém sinaliza deixa passar falhas silenciosas. Uma amostra aleatória evita os dois problemas. Como a amostra é escolhida ao acaso, as equipes não conseguem prever quais tickets serão conferidos; por isso, todo ticket precisa de evidência de que a correção funciona, como um resultado de reteste, um diff de configuração ou uma varredura. Se a amostra revelar evidência ausente, a parcela ausente na amostra estima a parcela ausente no total, e os métodos de intervalo usados para taxas de detecção também se aplicam a essa proporção.
15.6 PulseMap
As visões de cobertura precisam mostrar denominadores. Um bloco verde que diz noventa por cento de cobertura esconde a pergunta que importa: noventa por cento de quê. Se o PulseMap conta apenas os hosts do inventário de ativos, e o inventário não tem uma conta de nuvem criada no trimestre passado, a cobertura real é menor do que o bloco sugere. Por isso, cada visão de cobertura mostra a contagem por trás da porcentagem, como quarenta e cinco de cinquenta aplicações web registradas, e nomeia a fonte do total. Os leitores podem então ver quando o próprio denominador parece pequeno demais, o que muitas vezes é o achado mais importante do painel.
15.7 Amostragem aleatória de tickets fechados
A amostragem de tickets fechados é de cinco tickets por mês, escolhidos por um gerador de números aleatórios. A ausência de evidência de verificação reabre o ticket automaticamente. Sam publica a contagem de reaberturas para que a manipulação da métrica fique visível. O sorteio é registrado com sua semente, para que qualquer pessoa possa confirmar que os cinco tickets não foram escolhidos a dedo. A reabertura automática mantém a consequência impessoal. Não é Sam acusando uma equipe; é a regra se aplicando sozinha. Publicar a contagem de reaberturas também torna a melhoria visível. Quando as reaberturas de uma unidade de negócio caíram de três por mês para zero, a contagem em queda mostrou que suas correções agora estavam sendo verificadas, e não apenas fechadas.
15.8 Um dicionário para os termos das métricas
Um dicionário compartilhado define "tocado", "validado" e "fechado". Sam recusa blocos do PulseMap que usam palavras não definidas. A mesma palavra pode significar coisas diferentes para equipes diferentes. Para um desenvolvedor, fechado pode significar que o código foi mesclado; para as operações, que foi implantado; e, para os testadores, que um reteste passou. Um bloco que conta achados fechados não tem sentido até que a palavra seja fixada. Cada entrada do dicionário dá uma definição, o campo de dados ao qual ela corresponde, um exemplo e um contraexemplo. Quando um bloco novo é proposto, seus rótulos são conferidos contra o dicionário antes da publicação.
15.9 O que conta como tocado
"Tocado" significa um cartão de método concluído com evidência, não um ping. A briga de Sam no dicionário por essa palavra valeu uma semana. Pela definição frouxa, um host respondia a uma varredura de rede e por isso contava como coberto. Pela estrita, um método de teste planejado era concluído contra ele e deixava evidência. A diferença foi grande. A cobertura medida por varreduras ficava perto de cem por cento, enquanto a cobertura medida por métodos concluídos ficava em cerca de sessenta. A definição estrita era menos lisonjeira e muito mais útil, porque mostrava quais ativos nunca tinham sido realmente testados.
15.10 Um bloco verde com dois pontos de dados
O subtítulo "n=2" ao lado de um visto verde num bloco do PulseMap ensina mais que uma aula sobre tamanho de amostra. Sam deixa de propósito um bloco verde de n pequeno no ambiente de treinamento para provocar perguntas. O bloco mostra que os dois tickets amostrados tinham evidência de verificação, o que dá cem por cento com quase nenhuma informação. Os alunos que o veem geralmente começam dizendo que o controle está funcionando, e então alguém nota o n. A discussão que se segue cobre o que duas observações conseguem sustentar, quão largo é o intervalo e que desenho de bloco evitaria a leitura errada. Essa última pergunta levou à regra de que blocos com amostras muito pequenas não podem ficar verdes.
15.11 Aprovar as definições
A briga do dicionário terminou quando o CISO assinou as definições. Sam emoldura o PDF assinado na wiki da equipe. Palavras são controles. A assinatura encerrou a discussão ao fazer das definições uma política do banco, e não uma preferência da equipe de testes. As equipes que discordavam ainda podiam propor mudanças, mas por uma revisão com número de versão, não usando em silêncio o seu próprio significado num painel. Cada bloco do PulseMap agora cita a versão do dicionário que usa. Quando uma definição muda, os números antigos e novos não são plotados na mesma linha sem um marcador, para que um salto causado pela redefinição não seja confundido com uma mudança real.
15.12 Definições no papel
As definições de métricas assinadas ficam penduradas ao lado da máquina de café da equipe — o papel ainda funciona. Uma página impressa na parede é vista por pessoas que nunca abririam a wiki, incluindo visitantes de outras equipes que vêm perguntar o que um número significa. Seu uso principal é nas conversas rápidas. Quando alguém diz que um achado está fechado, um colega pode apontar para a definição e perguntar se o reteste passou. A página traz seu número de versão e sua data, de modo que uma impressão desatualizada é fácil de notar e substituir quando a versão assinada muda.
15.13 Um estado amarelo para termos não definidos
Blocos com palavras não definidas mostram um estado amarelo, "defina-me", em vez de verde. O amarelo é mais difícil de ignorar. Um bloco que usa um termo ausente do dicionário ainda mostra seu número, mas não pode ficar verde, porque ninguém sabe dizer o que o verde significaria. O estado amarelo nomeia a palavra não definida e leva ao formulário para propor uma definição. Isso evita duas opções piores. Esconder o bloco perde informação, e mostrá-lo verde dá uma falsa tranquilidade. Na prática, a maioria dos blocos amarelos é corrigida em uma semana, geralmente mapeando o rótulo para um termo existente.
15.14 Plantão de medição
O plantão de medição acontece às quintas-feiras. Qualquer pessoa pode trazer um bloco que pareça enganoso. A correção mais comum de Sam é acrescentar n ao subtítulo ou trocar o verde por amarelo. Ele acompanha quantos blocos mudam de cor a cada mês, como uma métrica de qualidade das métricas. O plantão dá às pessoas uma forma de baixo risco de questionar um número sem acusar quem construiu o bloco. Muitas queixas acabam sendo sobre rótulos, e não sobre dados. Um bloco que diz "incidentes" pode, na verdade, estar contando alertas, e a correção é um título melhor. Acompanhar as mudanças de cor mostra se o painel está ficando mais honesto com o tempo. Um mês sem mudanças significa ou que os blocos estão bons, ou que as pessoas pararam de vir.
Exemplo resolvido (TRB sintético)
Sam recusa uma captura de tela com hash divergente e a captura de novo.
Caso sintético — Riverstone Transit Bank (TRB). O banco, Sam Ito, TrackScope/FindingsDesk/PulseMap e todos os números são inventados para fins didáticos.
Erros e limites
Este livro não concede nenhuma autoridade para testar bancos ou sistemas de pagamento reais. Os laboratórios usam apenas endereços de faixas de documentação e dados sintéticos; código de exploit nunca é fornecido.
Exercícios
- EX043 — Vaidade. Por que rejeitar a contagem bruta de achados como KPI? Rubrica: 3 = recompensa o ruído; 2 = parcial; 1 = o melhor KPI; 0 = nada.
- EX044 — Significado do hash. O que um hash coincidente prova? Rubrica: 3 = inalterado desde o cálculo do hash; 2 = parcial; 1 = sistema seguro; 0 = nada.
- EX045 — Campos de custódia. Nomeie quatro campos de custódia. Rubrica: 3 = quem, o quê, quando, onde; 2 = três; 1 = um; 0 = nada.
Síntese
A evidência recebe hash e atribuição; as métricas trazem denominadores.
Continue estudando — capítulo 15 de 40
← Capítulo 14 (rascunho) · Índice de capítulos do curso · Capítulo 16 (rascunho) →