Capítulo 38 — Segurança ofensiva autorizada e red team: validação
Mapa da aula
Aula 38 publicada. Mapa, exemplo, EX112.
flowchart TD
N0["38.1 Desenho do novo teste"]
N1["38.2 Resultados negativos"]
N2["38.3 Nada de métodos novos"]
N3["38.2b Novos testes por amostragem"]
N4["38.3b Automatizar o novo teste com segurança"]
N5["38.1b Evidência da validação"]
N6["Nota de prática"]
N7["38.4b Comunicar um novo teste reprovado"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX112"]
Desenho lógico
flowchart LR
N0["38.1 Desenho do novo teste"]
N1["38.2 Resultados negativos"]
N2["38.3 Nada de métodos novos"]
N3["38.2b Novos testes por amostragem"]
N4["38.3b Automatizar o novo teste com segurança"]
N5["38.1b Evidência da validação"]
N6["Nota de prática"]
N7["38.4b Comunicar um novo teste reprovado"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX112"]
[38.1 Desenho do novo teste]
|
v
[38.2 Resultados negativos]
|
v
[38.3 Nada de métodos novos]
|
v
[38.2b Novos testes por amostragem]
|
v
[38.3b Automatizar o novo teste com segurança]
|
v
[38.1b Evidência da validação]
|
v
[Nota de prática]
|
v
[38.4b Comunicar um novo teste reprovado]
|
v
[Exemplo resolvido] --> [Exercício EX112]
Objetivos de aprendizagem
Você vai (1) validar correções com novos testes; (2) evitar uma validação que reintroduza risco; (3) registrar resultados negativos.
38.1 Desenho do novo teste
Mesmo ponto de observação, privilégio mínimo, mesmo padrão de evidência. Para senha padrão: confirme que o login falha; não faça spray de variantes. Fazer spray de variantes de senha transforma a validação num novo ataque. Confirmar que o login padrão falha, do mesmo ponto de observação e com o mesmo privilégio, basta para fechar o SYN-001. O cartão de novo teste de Sam cita a requisição exata e o 401 esperado, nada mais. Um pedido para tentar senhas alternativas no mesmo formulário é registrado como método recusado, não como minúcia. A recusa fica visível no ticket, para que um auditor depois veja que a fronteira foi mantida.
38.2 Resultados negativos
"Ainda aberto" é um resultado de validação válido. O PulseMap e o FindingsDesk precisam aceitá-lo sem forçar o fechamento. Forçar o fechamento de todo ticket ensina as pessoas a mentir quando uma correção falhou. "Ainda aberto" com evidência nova foi como o SYN-005 continuou honesto até que a participação no grupo de fato mudasse. O FindingsDesk aceita esse status sem motivo de fechamento, e o PulseMap o conta como validação incompleta, não como sucesso. Fechar o SYN-005 exigiu um segundo novo teste depois que a participação no grupo finalmente desapareceu, com um novo hash de evidência. O relógio do SLA não foi zerado no primeiro novo teste reprovado; continuou correndo até o segundo verde.
38.3 Nada de métodos novos
A validação usa o método que encontrou o problema, ou uma verificação mais fraca e só de leitura — não é uma chance de tentar novos ataques. A validação não é um segundo engajamento. Usar uma verificação mais fraca e só de leitura, ou o mesmo método que encontrou o problema, mantém a ROE estável. Sam rejeitou uma proposta de "só verificar mais uma porta" durante o novo teste do SYN-001; essa porta pertencia ao plano do próximo engajamento, se o cliente a quisesse.
Caso sintético — Riverstone Transit. Novo teste do SYN-001: o login padrão retornou 401; ticket fechado com hash de evidência. O SYN-005 ainda tinha a participação no grupo — ficou aberto.
38.4 Erros e limites
Ambiente diferente (homologação vs. produção) significa que você validou a homologação. Fechar um achado de produção porque a homologação parece corrigida é como as violações voltam depois da entrada em produção. O registro do novo teste precisa citar o ambiente. O modelo de ticket de Sam recusa um fechamento quando o campo de ambiente ainda diz homologação e o ativo do achado é de produção. Verdes da homologação podem ser anexados como notas de apoio, mas nunca como a única evidência de fechamento. Uma janela de novo teste em produção é reservada no mesmo calendário da descoberta, para que não possa ser esquecida.
38.2b Novos testes por amostragem
Quando muitos achados parecidos compartilham uma causa raiz (cabeçalho ausente em toda a frota), faça o novo teste numa amostra mais os hosts originalmente relatados, e diga isso. Alegar "todos os 200 fechados" depois de verificar cinco é uma mentira de medição. Refazer o teste de cada achado baixo pode consumir a janela; dizer que você amostrou, e como, mantém a afirmação honesta. Estratifique pela severidade, para que os críticos nunca fiquem no restante não amostrado. O relatório de validação de Sam para um engajamento de cinquenta achados listou os dez baixos amostrados e a regra que os escolheu. Os achados críticos e altos passaram por novo teste em 100% naquele engajamento; a amostra se aplicou só aos baixos.
38.3b Automatizar o novo teste com segurança
Novos testes automatizados são verificações de uma lista de permissão (status HTTP, leitura de participação em grupo) com tempos limite rígidos. Nunca incluem credential stuffing nem novas tentativas de exploração. Se a automação não consegue validar com segurança, agende uma verificação humana só de leitura. Uma automação que repete o caminho de exploração original está fora dos limites deste programa. Automação segura significa leituras autorizadas e códigos de status esperados, como a verificação do 401 no SYN-001. A biblioteca de automação de Sam não carrega para validação um cartão de método marcado como barulhento. Cartões marcados como silenciosos podem ser automatizados; qualquer coisa que precise de uma exceção ao limite de taxa continua manual.
38.1b Evidência da validação
Os tickets de validação apontam para o achado original, o método usado, o carimbo de tempo e o hash da nova evidência. "Para mim está bom" sem esses campos não fecha um crítico. Um comentário dizendo "parece corrigido" não é evidência. Os hashes da nova resposta, o horário, o ponto de observação e a conta pertencem ao ticket, da mesma forma que a evidência da descoberta. Sam só fecha quando esses campos estão presentes e o hash bate com o repositório selado. Um comentário de fechamento sem hash é rejeitado pelo FindingsDesk da mesma forma que uma severidade vazia.
Nota de prática
Disputas sobre a validação sobem para um papel de árbitro nomeado, com acesso aos dois hashes de evidência. O árbitro não ataca de novo; compara a evidência com a nota de aceitação. Documente a decisão no ticket, para que a discussão não recomece a cada reunião de status.
Exija o id do método de novo teste em toda transição para fechado nas severidades crítica e alta.
38.4b Comunicar um novo teste reprovado
Quando um novo teste mostra que uma correção não funcionou, o relatório diz isso com clareza, inclui a evidência e a data e evita sugerir culpa. O dono na Riverstone Transit recebe primeiro em particular, para que a equipe possa planejar uma nova correção antes que o resultado chegue a reuniões de governança mais amplas. Os donos merecem um "ainda aberto" claro com a nova evidência, não silêncio até a retrospectiva. A mensagem reutiliza o id do achado e evita novos detalhes de ataque. O modelo de Sam para o SYN-005 citou a participação no grupo ainda presente e o relógio do SLA ainda correndo, e depois ofereceu um horário de novo teste após a próxima mudança.
Exercícios
- EX112 — Novo teste. Passos para validar com segurança a correção da senha padrão. Rubrica: 3 = tentativa única, esperar falha, evidência, sem spray; 2 = parcial; 1 = spray; 0 = exploração.
- EX113 — Negativo. Por que "ainda aberto" precisa poder ser armazenado? Rubrica: 3 = honestidade/SLA; 2 = vago; 1 = sempre fechar; 0 = nada.
- EX114 — Ambiente. Uma frase de limitação quando o novo teste foi só na homologação. Rubrica: 3 = clara; 2 = vaga; 1 = alega produção; 0 = nada.
Síntese
Valide de forma estreita; guarde os negativos; não amplie os métodos.
Continue estudando — capítulo 38 de 50
← Capítulo 37 (rascunho) · Índice de capítulos do curso · Capítulo 39 (rascunho) →