Capítulo 21 — Operações de segurança e blue team: requisitos
Mapa da aula
Aula 21 publicada. Mapa, exemplo, EX061.
flowchart TD
N0["21.1 Fontes de requisitos"]
N1["21.2 Requisitos funcionais"]
N2["21.3 Requisitos não funcionais"]
N3["21.4 Redação mensurável"]
N4["21.5 Rastreabilidade"]
N5["21.6 Priorização"]
N6["21.7 Controle de mudanças"]
N7["Critérios de aceitação"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7
N7 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX061"]
Desenho lógico
flowchart LR
N0["21.1 Fontes de requisitos"]
N1["21.2 Requisitos funcionais"]
N2["21.3 Requisitos não funcionais"]
N3["21.4 Redação mensurável"]
N4["21.5 Rastreabilidade"]
N5["21.6 Priorização"]
N6["21.7 Controle de mudanças"]
N7["Critérios de aceitação"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> N7 --> Q["EX061"]
[21.1 Fontes de requisitos]
|
v
[21.2 Requisitos funcionais]
|
v
[21.3 Requisitos não funcionais]
|
v
[21.4 Redação mensurável]
|
v
[21.5 Rastreabilidade]
|
v
[21.6 Priorização]
|
v
[21.7 Controle de mudanças]
|
v
[Critérios de aceitação]
|
v
[Exemplo resolvido] --> [Exercício EX061]
Objetivos de aprendizagem
Você vai (1) levantar requisitos de SOC junto às partes interessadas e a partir das ameaças; (2) escrever requisitos funcionais e não funcionais mensuráveis; (3) rastrear requisitos até ameaças e testes; (4) priorizar requisitos sob restrições.
21.1 Fontes de requisitos
Os requisitos vêm da missão, das ameaças, das regulações, dos incidentes e das dores dos analistas. O incidente do portal produziu o requisito "detectar provável tomada de conta no portal do cliente em até 15 minutos". Cada fonte puxa numa direção. As ameaças sugerem o que os atacantes vão tentar; as regulações definem mínimos, como a retenção; os incidentes expõem lacunas que de fato machucaram; as dores dos analistas revelam onde o trabalho é desperdiçado com regras ruidosas ou falta de contexto. Coletar de todas elas evita um conjunto de requisitos que reflita apenas a voz mais alta, e a fonte de cada um é registrada ao lado dele.
21.2 Requisitos funcionais
Dizem o que o sistema faz: ingerir os logs do balanceador de carga; correlacionar falhas e sucessos por rede; gerar um alerta com o ID do cliente, a rede de origem e as ações subsequentes. Cada enunciado é formulado como algo que o sistema precisa fazer, para que um testador possa conferi-lo diretamente: alimentar logs do balanceador e ver se são ingeridos; criar uma rajada de falhas seguida de um sucesso e ver se a correlação dispara; abrir o alerta e ver se ele traz os três campos nomeados. Verbos vagos como "suportar" ou "tratar" são evitados.
21.3 Requisitos não funcionais
Dizem quão bem: latência abaixo de 5 minutos do evento ao alerta; disponibilidade de 99,5% para o pipeline; no máximo 10 alertas falsos por dia para o turno da noite; dados retidos por 90 dias na camada quente. Essas qualidades são muitas vezes onde os sistemas decepcionam, porque são fáceis de esquecer durante o projeto. Uma regra logicamente perfeita, mas que alerta vinte minutos atrasada, perde a meta. Uma meta de disponibilidade de 99,5% admite cerca de 44 horas de indisponibilidade do pipeline por ano, que Amara compara com as janelas de manutenção já planejadas, para conferir se o número é realista.
21.4 Redação mensurável
"Rápido" e "preciso" não podem ser testados. Cada requisito declara um número, uma condição e um método de medição. Por exemplo, "rápido" vira "95% dos alertas criados em até 5 minutos após o evento que os aciona, medidos do horário do evento ao horário do alerta ao longo de um mês civil". O método importa tanto quanto o número: medir a partir do horário de ingestão, e não do horário do evento, esconderia atrasos na entrega dos logs e faria o pipeline parecer melhor do que é. Amara reescreve todos os requisitos nessa forma e pede a Paolo que tente escrever um teste para cada um; o que ele não conseguir testar volta para ser reescrito.
21.5 Rastreabilidade
Uma tabela liga cada requisito à sua fonte (ameaça, regulação, incidente), ao elemento de projeto que o atende e ao teste que o verifica. Os IDs de técnicas do ATT&CK dão uma referência comum para as fontes de ameaça. A tabela funciona nos dois sentidos. Lendo para a frente, a partir de uma ameaça, vê-se se algo a trata; lendo para trás, a partir de um teste, vê-se por que ele existe. Uma regulação alterada é rastreada do mesmo modo, de sua linha até os requisitos e testes que a citam. Usar IDs de técnicas permite à equipe de segurança e aos relatórios externos se referirem à mesma ameaça sem ambiguidade.
21.6 Priorização
Com equipe limitada, Amara e Paolo classificam os requisitos como obrigatório, desejável ou opcional, guiados pelo risco e pelo custo. Um obrigatório é algo sem o qual o sistema falha em seu propósito, como detectar a tomada de conta; um desejável acrescenta valor real, mas pode esperar, como enriquecer os alertas com o nível do cliente; um opcional é bom de ter. Classificar abertamente permite aos gestores ver o que não será entregue neste trimestre, em vez de descobrirem isso mais tarde, quando o tempo acabar. Os obrigatórios são financiados primeiro; os opcionais esperam capacidade ociosa.
21.7 Controle de mudanças
Os requisitos mudam; cada mudança é registrada com motivo e aprovação, e os testes afetados são atualizados. Sem isso, os requisitos se deslocam em silêncio por meio de conversas, e os testes acabam verificando algo com que ninguém concordou. Registrar o motivo mantém as mudanças honestas: baixar o limite de alertas falsos porque os analistas reclamaram é diferente de baixá-lo porque o turno da noite foi reduzido. Atualizar os testes junto mantém a verificação alinhada com o que agora se espera do sistema. Paolo aprova cada mudança, e o requisito mantém seu histórico, para que resultados de testes anteriores ainda possam ser interpretados em relação à versão vigente na época.
Critérios de aceitação
Cada requisito tem critérios de aceitação acordados antes da construção: que resultado em qual teste conta como aprovado. Acordá-los cedo evita discussões posteriores sobre se o trabalho está pronto e dá aos analistas uma promessa clara do que a nova detecção vai entregar.
Exemplo resolvido
O requisito R-07 de Amara diz: "O pipeline deve gerar um alerta de possível tomada de conta em até 15 minutos após um login bem-sucedido no portal que se siga a pelo menos 6 falhas para usuários distintos a partir da mesma /24 em 10 minutos; verificado mensalmente por um evento sintético cronometrado." Paolo o aprova como obrigatório.
Caso sintético. Os requisitos são inventados.
Erros e limites
Requisitos demais se tornam ingerenciáveis; concentre-se nos ligados a riscos reais.
Exercícios
- EX061 — Funcional versus não funcional. Dê um requisito funcional e um não funcional do caso. Rubrica: 3 = por exemplo, correlacionar falhas/sucessos; latência abaixo de 5 minutos; 2 = um; 1 = confuso; 0 = nada.
- EX062 — Redação mensurável. Reescreva "os alertas precisam ser rápidos" como um requisito mensurável. Rubrica: 3 = número, condição, medição; 2 = parcial; 1 = inalterado; 0 = nada.
- EX063 — Tabela de rastreabilidade. Que colunas tem a tabela de rastreabilidade? Rubrica: 3 = requisito, fonte, elemento de projeto, teste; 2 = três; 1 = uma; 0 = nada.
Síntese
Requisitos mensuráveis, rastreáveis e priorizados transformam incidentes e ameaças em trabalho de engenharia.
Continue estudando — capítulo 21 de 50
← Capítulo 20 (rascunho) · Índice de capítulos do curso · Capítulo 22 (rascunho) →