Capítulo 21 — Segurança ofensiva autorizada e red team: requisitos
Mapa da aula
Aula 21 publicada. Mapa, exemplo, EX061.
flowchart TD
N0["21.1 Fontes de requisitos"]
N1["21.2 Três famílias"]
N2["21.3 Critérios de aceitação"]
N3["21.3b Ids de requisitos no código"]
N4["21.1b MoSCoW sob a segurança"]
N5["Nota de prática"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX061"]
Desenho lógico
flowchart LR
N0["21.1 Fontes de requisitos"]
N1["21.2 Três famílias"]
N2["21.3 Critérios de aceitação"]
N3["21.3b Ids de requisitos no código"]
N4["21.1b MoSCoW sob a segurança"]
N5["Nota de prática"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX061"]
[21.1 Fontes de requisitos]
|
v
[21.2 Três famílias]
|
v
[21.3 Critérios de aceitação]
|
v
[21.3b Ids de requisitos no código]
|
v
[21.1b MoSCoW sob a segurança]
|
v
[Nota de prática]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX061]
Objetivos de aprendizagem
Você vai (1) levantar requisitos a partir da ROE e dos operadores; (2) separar requisitos funcionais, de segurança e de medição; (3) escrever critérios de aceitação que um testador consiga executar.
21.1 Fontes de requisitos
Os operadores querem menos bloqueios falsos; a assessoria jurídica quer uma trilha de auditoria; o cliente quer achados claros. As entrevistas de levantamento produzem declarações com "deve" marcadas pela fonte. Os conflitos (velocidade vs. etapas de aprovação) são registrados, não escondidos. Fontes marcadas tornam os conflitos discutíveis: velocidade contra etapas de aprovação vira um trade-off registrado, com um dono. Escondê-lo produz uma ferramenta em que ninguém confia. Sam mantém o log de conflitos ao lado do arquivo de requisitos, para que um novo líder veja as discussões antigas sem precisar repeti-las. Cada entrada de conflito registra quem o levantou e qual declaração com "deve" o resolveu.
21.2 Três famílias
Funcional: "O TrackScope avalia allowed(host,port) antes de cada ação." Segurança: "O TrackScope falha fechado se o arquivo de política não carregar." Medição: "O PulseMap relata contagens de técnicas planejadas vs. observadas, com denominadores." Os requisitos de segurança vencem os empates. A segurança vencer os empates significa que um caminho rápido que pule a carga da política é rejeitado, mesmo que os testadores aplaudam. Os requisitos de medição obrigam a ter denominadores, para que a cobertura não seja uma contagem solta. Os requisitos funcionais nomeiam o momento da verificação, como antes de cada ação. Sam colore as linhas de segurança nas revisões, para que não possam ser negociadas para baixo em silêncio.
21.3 Critérios de aceitação
Cada requisito tem um Dado/Quando/Então sobre dados sintéticos. Exemplo: Dada a lista de exclusão {10.20.0.1}, Quando sondar 10.20.0.1:443, Então DENY deny-list e um evento é armazenado. Critérios que precisam de uma rede real de cliente são rejeitados na revisão. Dado/Quando/Então sintético mantém a CI honesta e mantém as redes dos clientes fora da bancada de testes. Critérios que precisam da produção são reprojetos, não metas ambiciosas. O exemplo da lista de exclusão é copiado para a suíte do TrackScope como um teste nomeado. Sam reprova a revisão quando um requisito Must não tem um critério assim.
Caso sintético — Riverstone Transit. O requisito de segurança S-3, "falhar fechado se a política estiver ausente", falhou no teste de aceitação quando um caminho com erro de digitação retornou ALLOW. A correção foi lançada antes de qualquer uso num engajamento.
21.4 Erros e limites
As partes interessadas inventam requisitos no meio do engajamento; estacione-os num backlog com um ticket de autorização, não aplique patches a quente no TrackScope de produção durante uma janela de teste ativa. Aplicar patches a quente no TrackScope no meio da janela arrisca um erro de falha aberta enquanto o tráfego está fluindo. Backlog mais ticket de autorização é o único caminho para ideias novas durante um teste. O script de plantão de Sam diz: nenhuma mudança de configuração em produção, exceto parar e revogar. Ideias de funcionalidade levantadas na sala de crise vão para a fila de tickets na mesma hora e continuam intocadas em produção até que uma mudança assinada entre depois da janela.
21.3b Ids de requisitos no código
Coloque os ids de requisitos nos nomes dos testes e nos campos de log (req=S-3). Quando acontece um incidente, poder buscar vale mais que um slide que um dia mapeou requisitos para módulos. Requisitos mortos sem testes devem fazer a CI falhar. Ids buscáveis transformam um canal de incidente num índice. Testes nomeados por requisitos mortos fazem a CI falhar até que alguém os apague ou substitua. Os campos de log carregam os mesmos ids, para que um evento de negação aponte para o S-3 sem uma apresentação de slides. Sam procura por req= nas revisões de incidente antes de atribuir culpa.
21.1b MoSCoW sob a segurança
A priorização Must/Should/Could continua colocando todos os requisitos de segurança em Must. Um Could que enfraquece um Must (lista de exclusão opcional) é reclassificado ou rejeitado. Gerentes de produto não vencem a falha fechada no voto. Listas de exclusão opcionais não são itens Could; elas quebram um Must. Gerentes de produto que querem um modo de demonstração que carregue sem política recebem uma recusa registrada. O quadro de priorização de Sam tem uma raia fixa para os Musts de segurança, que não pode ser arrastada para Should. Modos de demonstração que pulam a carga da política são fechados como wontfix, com um link para esta regra.
Nota de prática
Os testes de aceitação são nomeados pelos ids dos requisitos e fazem a CI falhar quando são pulados. Um painel de requisitos sem testes é revisado toda semana no ateliê. Requisitos Must órfãos são testados ou formalmente adiados com um dono executivo — silêncio não é adiamento. Esse hábito é o que transforma uma planilha de requisitos em algo que ainda importa na sexta-feira antes de um engajamento.
Exercícios
- EX061 — Levantamento. Escreva um "deve" funcional e um de segurança a partir de "nunca podemos atingir o gateway". Rubrica: 3 = ambos testáveis; 2 = um; 1 = vago; 0 = nada.
- EX062 — Aceitação. Dê um Dado/Quando/Então para falhar fechado com a política ausente. Rubrica: 3 = completo, com DENY/erro esperado; 2 = parcial; 1 = ideia; 0 = nada.
- EX063 — Conflito. Velocidade vs. aprovação dupla para ampliar o escopo — registre o conflito e a regra escolhida. Rubrica: 3 = conflito nomeado + regra de segurança em primeiro lugar; 2 = só a regra; 1 = escolhe a velocidade; 0 = nada.
Síntese
Os requisitos vêm das pessoas, se dividem em famílias e são entregues com testes de aceitação sobre fixtures sintéticos.
Continue estudando — capítulo 21 de 50
← Capítulo 20 (rascunho) · Índice de capítulos do curso · Capítulo 22 (rascunho) →