Capítulo 7 — Controles e verificação
Mapa da aula
Aula 07 publicada. Mapa, exemplo, EX031.
flowchart TD
N0["7.1 Associar o controle à constatação"]
N1["7.2 Controles compensatórios"]
N2["7.3 Desenho do reteste"]
N3["7.4 O que significa verificado"]
N4["7.5 Acompanhamento"]
N5["7.6 Correções parciais"]
N6["7.7 Responsáveis pela verificação"]
N7["7.8 Vigilância de regressões"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX031"]
Desenho lógico
flowchart LR
N0["7.1 Associar o controle à constatação"]
N1["7.2 Controles compensatórios"]
N2["7.3 Desenho do reteste"]
N3["7.4 O que significa verificado"]
N4["7.5 Acompanhamento"]
N5["7.6 Correções parciais"]
N6["7.7 Responsáveis pela verificação"]
N7["7.8 Vigilância de regressões"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX031"]
[7.1 Associar o controle à constatação]
|
v
[7.2 Controles compensatórios]
|
v
[7.3 Desenho do reteste]
|
v
[7.4 O que significa verificado]
|
v
[7.5 Acompanhamento]
|
v
[7.6 Correções parciais]
|
v
[7.7 Responsáveis pela verificação]
|
v
[7.8 Vigilância de regressões]
|
v
[Exemplo resolvido] --> [Exercício EX031]
Objetivos de aprendizagem
Você vai (1) sugerir controles compatíveis com as constatações; (2) distinguir controles compensatórios; (3) planejar um reteste; (4) saber quando um controle está verificado.
7.1 Associar o controle à constatação
Uma constatação de senha de administrador compartilhada pede contas nominais e cofre de senhas; um open redirect pede destinos em lista de permissões; um atributo ausente no cookie pede o atributo configurado e verificado na CI. Leo escreve cada recomendação de acordo com a constatação: contas nominais na VPN e um cofre para senhas compartilhadas; destinos em lista de permissões para um open redirect; atributos Secure e HttpOnly verificados na CI para o cookie de sessão. A equipe de segurança de aplicações é responsável por Secure e HttpOnly na constatação do cookie-flag, e a linha da recomendação traz esse nome e um prazo. Conselhos genéricos como "endurecer a aplicação" ou "endurecer as sessões" não dizem a um responsável o que mudar.
7.2 Controles compensatórios
Quando a correção ideal está a meses de distância, um controle compensatório reduz o risco agora — por exemplo, caminhos administrativos da VPN restritos aos jump hosts enquanto a reutilização de senhas é eliminada. Leo registra o controle compensatório como temporário, com um responsável e uma data para rever a correção ideal, para que ele não se torne permanente por descuido. Restrições temporárias de rede em torno de um banner desatualizado são aceitáveis nos mesmos termos: depois que o banner recebe o patch, as regras de acesso saem do ticket com uma nota de reteste e um registro de horário de retirada. Compensações sem prazo viram dívida esquecida.
7.3 Desenho do reteste
Reteste apenas as constatações acordadas, com o mesmo método ou um equivalente, depois que o responsável disser que a correção está no ar. Registre aprovação ou reprovação com evidências. Depois que o responsável diz que os atributos do cookie estão no ar na homologação, Leo repete a mesma verificação com a versão de ferramenta registrada, e a aprovação ou reprovação vai para o ticket com uma captura de tela nova. Ele confere nomes de host, portas e versões de build com a nota de mudança do responsável antes de declarar que um reteste falhou. Um reteste que toque um host fora da lista original do ENG-440 espera uma atualização de escopo por escrito, e retestar constatações sem relação desperdiça a janela.
7.4 O que significa verificado
Verificado significa que Leo reproduziu o sintoma original e o viu corrigido (ou confirmou que o controle compensatório funciona), e não que o responsável disse que corrigiu. A confirmação de implantação pelo responsável é necessária, mas não suficiente. Leo ou outro testador precisa ver que o sintoma original sumiu, ou que o controle compensatório funciona, antes de o ticket ser marcado como verificado. As capturas de tela do cookie, de antes e depois, entram no cofre com hash e são vinculadas ao T-15, para que a verificação seja evidência no registro, e não uma garantia verbal de que alguém acha que está corrigido.
7.5 Acompanhamento
As constatações viram tickets com responsáveis e datas; a verificação os fecha. Cada constatação da HCU vira um ticket com um responsável e um prazo, e as evidências de verificação o fecham. Tickets sem responsáveis ou datas escondem risco no backlog, e é por isso que o lab_ticket do capítulo 10 sinaliza campos incompletos: ele marca o T-15 como incompleto em owner e verified, e o T-18 como incompleto em due date, e esses nunca contam como prontos para fechamento. Toda sexta-feira, Leo abre o rastreador, e campos de responsável ou prazo em branco são escalados na mesma semana, em vez de envelhecerem até virar constatações de exame.
7.6 Correções parciais
Às vezes, os responsáveis corrigem um caminho e deixam outro aberto. A checklist de reteste de Leo nomeia cada caminho da constatação original. Um ticket não é fechado até que nenhum dos caminhos listados reproduza o problema ou que um controle compensatório aceito seja verificado. Em um open redirect, Leo lista cada parâmetro e caminho da constatação original; fechar depois de corrigir apenas um deixa os associados expostos nos outros. Se um caminho de redirecionamento continuar aberto depois de uma correção parcial, o CISO o aceita por escrito, com prazo de expiração, ou o ticket permanece aberto no rastreador até que o risco residual tenha responsável ou seja eliminado.
7.7 Responsáveis pela verificação
Quem aplica uma correção não deve ser a única pessoa a marcá-la como verificada. Leo ou outro testador retesta; o responsável confirma a implantação. A separação mantém os fechamentos otimistas fora das métricas: "corrigido porque eu implantei" não sobrevive a um reteste separado. A mesma regra vale para Leo, então um colega verifica qualquer controle compensatório que ele tenha aplicado, e o fechamento nunca depende das mesmas mãos que fizeram a mudança. Métricas que contam tickets verificados só depois da assinatura de um testador separado mantêm os números honestos para o CISO e os examinadores.
7.8 Vigilância de regressões
Depois de uma correção, Leo pergunta se os caminhos relacionados foram verificados pelo responsável. Um open redirect corrigido que deixa um segundo parâmetro intocado é uma regressão comum; o plano de reteste nomeia os caminhos irmãos quando existem. Quando o responsável corrige um parâmetro de redirecionamento, o plano de reteste de Leo já nomeia os parâmetros irmãos da constatação, e regressões custam menos quando detectadas na mesma janela do que no próximo ciclo de exame. A vigilância de regressões depois do ENG-440 também verifica se os atributos do cookie e as correções de redirecionamento continuam nos builds seguintes. Uma correção que desaparece na próxima implantação da homologação reabre o ticket com o identificador do build anexado.
Exemplo resolvido (HCU sintética)
Para a senha de administrador compartilhada da VPN, a HCU habilita MFA e contas nominais em duas semanas (ideal) e, enquanto isso, restringe os caminhos administrativos ao jump host (compensatório). Leo retesta os dois.
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
- EX031 — Associação de controle. Sugira um controle para um open redirect. Rubrica: 3 = lista de permissões para os destinos de redirecionamento / remover o parâmetro; 2 = parcial; 1 = "firewall"; 0 = nada.
- EX032 — Exemplo compensatório. Dê um controle compensatório para a reutilização de senhas na administração da VPN. Rubrica: 3 = restringir a administração ao jump host / MFA / monitoramento; 2 = parcial; 1 = ignorar; 0 = nada.
- EX033 — Gatilho do reteste. Quando o reteste começa? Rubrica: 3 = depois que o responsável confirma a correção no ar / na janela acordada; 2 = parcial; 1 = sempre imediatamente; 0 = nada.
- EX034 — Não verificado. O responsável envia um e-mail dizendo "corrigimos" sem detalhes. Está verificado? Rubrica: 3 = não; são necessárias evidências de reteste; 2 = não; 1 = sim; 0 = nada.
- EX035 — Escopo do reteste. Leo pode testar URLs novas sem relação durante o reteste? Rubrica: 3 = não; só as constatações acordadas, a menos que o escopo seja ampliado; 2 = não; 1 = sim; 0 = nada.
Síntese
Os controles correspondem às constatações; os controles compensatórios compram tempo; a verificação é um reteste com evidências.
Continue estudando — capítulo 07 de 12
← Capítulo 06 (rascunho) · Índice de capítulos do curso · Capítulo 08 (rascunho) →