Capítulo 5 — Ferramentas e interpretação
Mapa da aula
Aula 05 publicada. Mapa, exemplo, EX021.
flowchart TD
N0["5.1 As ferramentas ajudam"]
N1["5.2 Piso de confiança"]
N2["5.3 Falsos positivos e negativos"]
N3["5.4 Versões e configurações"]
N4["5.5 O OWASP WSTG como ferramenta de raciocínio"]
N5["5.6 Interpretar banners"]
N6["5.7 Taxas de base"]
N7["5.8 Verificações manuais por amostragem"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX021"]
Desenho lógico
flowchart LR
N0["5.1 As ferramentas ajudam"]
N1["5.2 Piso de confiança"]
N2["5.3 Falsos positivos e negativos"]
N3["5.4 Versões e configurações"]
N4["5.5 O OWASP WSTG como ferramenta de raciocínio"]
N5["5.6 Interpretar banners"]
N6["5.7 Taxas de base"]
N7["5.8 Verificações manuais por amostragem"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX021"]
[5.1 As ferramentas ajudam]
|
v
[5.2 Piso de confiança]
|
v
[5.3 Falsos positivos e negativos]
|
v
[5.4 Versões e configurações]
|
v
[5.5 O OWASP WSTG como ferramenta de raciocínio]
|
v
[5.6 Interpretar banners]
|
v
[5.7 Taxas de base]
|
v
[5.8 Verificações manuais por amostragem]
|
v
[Exemplo resolvido] --> [Exercício EX021]
Objetivos de aprendizagem
Você vai (1) tratar scanners como assistentes, e não como juízes; (2) filtrar constatações por confiança e confirmação; (3) explicar falsos positivos e falsos negativos; (4) registrar as versões das ferramentas nas evidências.
5.1 As ferramentas ajudam
Scanners e checklists aceleram a descoberta. Eles rotulam errado, perdem o contexto e não conseguem julgar o impacto de negócio. Leo lê todo item mantido: quando o lab_severity mantém três de cinco itens, ele ainda abre cada item mantido e pergunta se a HCU deveria agir. Itens que ele não consegue explicar em palavras simples quanto ao impacto sobre os associados voltam para mais validação ou são descartados. Os dois itens descartados, dir-listing e trace-method, são anotados no apêndice de método, para que ninguém se pergunte se foram ignorados. Os scanners ajudam na descoberta; eles não julgam o impacto sobre os associados nem escrevem a recomendação.
5.2 Piso de confiança
A HCU descarta itens não confirmados abaixo de um piso de confiança, para que o relatório não seja inflado com ruído.
"""Lab 5: filter a synthetic tool finding list, dropping noise below a confidence floor."""
findings = [("open-redirect", 0.9, True), ("dir-listing", 0.4, False),
("outdated-banner", 0.7, True), ("cookie-flag", 0.85, True), ("trace-method", 0.3, False)]
FLOOR = 0.6
kept = [(n, c) for n, c, confirmed in findings if c >= FLOOR and confirmed]
for n, c in kept:
print(f"KEEP {n:16} confidence={c}")
print(f"kept {len(kept)} of {len(findings)}; dropped {len(findings)-len(kept)}")
Execute com python3 lab_severity.py. Saída verificada:
KEEP open-redirect confidence=0.9
KEEP outdated-banner confidence=0.7
KEEP cookie-flag confidence=0.85
kept 3 of 5; dropped 2
Com FLOOR em 0.6, o laboratório mantém open-redirect (0.9), outdated-banner (0.7) e cookie-flag (0.85) e descarta o resto. Dir-listing e trace-method ficam abaixo de 0.6, por isso permanecem no apêndice de saída bruta, e não na lista de constatações, e itens não confirmados abaixo do piso nunca aparecem nos slides executivos. Subir o piso para 0.8 descartaria também o banner. Leo declara o piso nas notas de método, para que os leitores saibam o que foi filtrado.
5.3 Falsos positivos e negativos
Um falso positivo desperdiça o tempo de quem corrige; um falso negativo deixa o risco. A amostragem e a validação manual reduzem os dois; nenhum chega a zero. Leo planeja o tempo de validação a partir das taxas históricas de falsos positivos e aceita que algum risco ainda possa escapar. Se os falsos positivos da última revisão se concentraram em uma verificação do scanner, essa verificação ganha tempo extra de validação no ENG-440. Na dúvida, ele valida mais em vez de entregar uma lista maior. Ele diz ao CISO que o relatório contém itens validados, e não que todos os problemas possíveis foram encontrados.
5.4 Versões e configurações
Registre o nome da ferramenta, a versão e o perfil junto com as evidências, para que um reteste possa usar a mesma configuração. As evidências de Leo para a constatação do cookie-flag nomeiam o scanner, sua versão e o perfil usado, e o nome do perfil fica registrado no ticket T-15, para que o reteste depois da correção da equipe de segurança de aplicações repita a mesma verificação com as mesmas configurações de varredura. Sem versões, um reteste que falha não consegue dizer se a correção falhou ou se a configuração mudou. Configurações que mudam no meio do engajamento são registradas com o horário da mudança, para que as evidências continuem dizendo qual configuração produziu cada resultado.
5.5 O OWASP WSTG como ferramenta de raciocínio
Mesmo sem scanner, o WSTG oferece uma lista estruturada de verificações web, para que a cobertura fique visível. Leo usa uma checklist derivada do WSTG para a homologação do internet banking, para mostrar quais verificações foram executadas e quais estavam fora do escopo. As linhas são marcadas como executada, não executada ou fora do escopo, e cada linha executada aponta para seu arquivo de evidência no cofre. A cobertura que existe só na cabeça dele não pode ser revisada nem retestada. Linhas vazias na checklist são lacunas honestas; inventar cobertura não ajuda ninguém quando os examinadores perguntam o que foi realmente testado.
5.6 Interpretar banners
Um banner desatualizado é uma pista, não uma crise. Leo verifica se o serviço está exposto à internet, se a versão é realmente vulnerável e se um WAF ou uma regra de acesso já limita a exposição antes de escrever uma constatação de severidade alta. Na camada de homologação da HCU, um banner desatualizado atrás de regras de acesso pode ter baixa prioridade; o mesmo banner em uma porta administrativa exposta à internet não teria. Para o banner do ENG-440, Leo registra que a homologação fica atrás de regras de acesso, e é por isso que ele não é classificado como alto. Ele escreve esse raciocínio na constatação, para que a severidade não seja um rótulo misterioso desligado do impacto sobre os associados; o contexto transforma uma pista em uma constatação proporcional.
5.7 Taxas de base
Se um scanner marca quarenta itens e o histórico mostra que trinta foram falsos positivos, Leo planeja o tempo de validação de acordo: quarenta itens brutos com esse histórico sugerem cerca de dez constatações reais. As taxas de base protegem o cronograma. Ele não promete ao CISO "quarenta constatações" antes da validação, porque isso cria a expectativa errada e pressiona a equipe a manter ruído. O tempo de validação faz parte do orçamento do engajamento, não é hora extra opcional, e Leo promete um conjunto validado com um prazo definido para a confirmação.
5.8 Verificações manuais por amostragem
A cada cinco itens automatizados mantidos, Leo valida manualmente, de ponta a ponta e com uma conta autorizada, pelo menos o de maior severidade. As verificações por amostragem detectam erros sistemáticos das ferramentas que uma pontuação de confiança não detecta, porque esses erros aparecem quando um humano repete o caminho. No ENG-440, o lab_severity mantém três itens e open-redirect, em 0.9, é o mais alto, por isso Leo percorre esse caminho primeiro, com uma conta autorizada, antes de o relatório ser redigido. Se o percurso do open-redirect falhar, os outros itens mantidos passam pelo mesmo caminho humano antes da redação do relatório.
Exemplo resolvido (HCU sintética)
Leo filtra a lista sintética: open-redirect, outdated-banner e cookie-flag são mantidos; dir-listing e trace-method são descartados. Ele ainda valida manualmente os três itens mantidos antes que entrem no relatório.
Caso sintético — Harborline Credit Union (HCU). A cooperativa de crédito, Leo Okonkwo e todos os números foram inventados para fins didáticos.
Erros e limites
Políticas e leis locais variam; siga a autorização da HCU e a sua jurisdição. Este livro nunca autoriza testes em sistemas reais.
Exercícios
- EX021 — Contagem do laboratório. Quantas constatações o laboratório mantém, e quais são descartadas? Rubrica: 3 = 3 mantidas; dir-listing e trace-method descartadas; 2 = só a contagem; 1 = errado; 0 = nada.
- EX022 — Subir o piso. Se FLOOR passar a 0.8, quais itens permanecem? Rubrica: 3 = só open-redirect e cookie-flag; 2 = um; 1 = os três; 0 = nada.
- EX023 — Falso positivo. Dê um exemplo de falso positivo na HCU. Rubrica: 3 = o scanner aponta um problema que a configuração da homologação mostra estar mitigado; 2 = parcial; 1 = vago; 0 = nada.
- EX024 — Falso negativo. Dê um exemplo de falso negativo na HCU. Rubrica: 3 = o problema existe, mas a ferramenta não o detecta (por exemplo, falha na lógica de autenticação); 2 = parcial; 1 = vago; 0 = nada.
- EX025 — Nota de versão. Escreva a linha sobre a ferramenta que Leo acrescenta às evidências. Rubrica: 3 = nome, versão, perfil/configurações; 2 = só o nome; 1 = vago; 0 = nada.
Síntese
As ferramentas propõem; as pessoas decidem — filtrar, validar, registrar versões e só então relatar.
Continue estudando — capítulo 05 de 12
← Capítulo 04 (rascunho) · Índice de capítulos do curso · Capítulo 06 (rascunho) →