Capítulo 21 — Inteligência de ameaças e OSINT: requisitos
Mapa da aula
Aula 21 publicada. Mapa, exemplo, EX061.
flowchart TD
N0["21.1 PIRs"]
N1["21.2 Do PIR ao requisito de sistema"]
N2["21.3 Redação verificável"]
N3["21.4 Requisitos não funcionais"]
N4["21.5 Matriz de rastreabilidade"]
N5["Nota de prática — Revisões de requisitos"]
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 PIRs"]
N1["21.2 Do PIR ao requisito de sistema"]
N2["21.3 Redação verificável"]
N3["21.4 Requisitos não funcionais"]
N4["21.5 Matriz de rastreabilidade"]
N5["Nota de prática — Revisões de requisitos"]
N6["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX061"]
[21.1 PIRs]
|
v
[21.2 Do PIR ao requisito de sistema]
|
v
[21.3 Redação verificável]
|
v
[21.4 Requisitos não funcionais]
|
v
[21.5 Matriz de rastreabilidade]
|
v
[Nota de prática — Revisões de requisitos]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX061]
Objetivos de aprendizagem
Você vai (1) coletar requisitos prioritários de inteligência (PIRs) junto às partes interessadas; (2) transformar PIRs em requisitos de sistema; (3) escrever requisitos verificáveis; (4) manter a rastreabilidade.
21.1 PIRs
Requisitos prioritários de inteligência são perguntas que os tomadores de decisão precisam ver respondidas: "Quais adversários miram distribuidoras de eletricidade na nossa região?" "Nossos fornecedores de OT estão sendo visados?" Eles orientam a coleta e a análise e devem ser revistos a cada trimestre. Kofi reuniu as perguntas da BEN perguntando ao CISO, ao líder do SOC e ao chefe de operações de rede o que eles gostariam de saber antes de sua próxima grande decisão. Muitas respostas se sobrepunham, e cinco perguntas cobriam quase tudo o que foi pedido. Uma pergunta sobre a qual ninguém pode agir é descartada, por mais interessante que pareça aos analistas.
21.2 Do PIR ao requisito de sistema
Um PIR sobre fornecedores de OT implica requisitos: ingerir os avisos dos fornecedores; marcar os objetos com o nome dos fornecedores; alertar quando uma campanha mencionar um fornecedor marcado. Cada um é uma declaração com "deve" e um método de verificação. Kofi escreve o método de verificação ao lado de cada declaração no momento em que a escreve: um teste com dados sintéticos, uma inspeção de configuração ou uma medição nos registros de produção. Se ele não consegue dizer como uma declaração seria verificada, a redação ainda não está precisa o bastante. Cada requisito também indica a pergunta a que serve, para que seu propósito continue visível depois que quem perguntou tiver seguido adiante.
21.3 Redação verificável
"O sistema deve ser rápido" não pode ser verificado. "O Lantern deve entregar indicadores com confiança ≥ 70 à aplicação por DNS em TI em até 30 minutos após a ingestão, para 95% dos indicadores em cada mês" pode. A segunda versão nomeia a população, o limiar, o destino, o prazo, a fração que precisa cumpri-lo e o período em que é julgada. Os registros do Lantern guardam os horários de ingestão e de entrega, então o número pode ser calculado todo mês sem esforço extra. Kofi reescreveu uma dúzia de declarações vagas nessa forma; três se mostraram impossíveis de medir com o registro atual, o que virou itens de trabalho próprios.
21.4 Requisitos não funcionais
Confidencialidade (aplicação do TLP), integridade (verificação de assinatura onde oferecida), disponibilidade (99,5% ao mês), privacidade (nenhuma coleta em redes sociais pessoais), retenção e auditabilidade também são requisitos, não reflexões tardias. Cada um deles é escrito e testado como qualquer declaração funcional. O requisito de privacidade, por exemplo, é verificado inspecionando o registro de fontes e o código dos coletores em busca de qualquer conector de rede social. A disponibilidade é medida por verificações de saúde a cada minuto. Deixar essas necessidades sem registro costuma significar descobri-las durante um incidente ou uma auditoria, quando mudar o projeto custa muito mais.
21.5 Matriz de rastreabilidade
Uma tabela liga PIRs → requisitos → elementos de projeto → testes. Quando um PIR é aposentado, seus requisitos podem ser revistos para remoção. Kofi mantém a tabela em uma planilha gerada a partir de marcações no documento de requisitos e dos nomes dos testes, de modo que ela se atualiza sozinha em vez de depender de alguém para editá-la. As lacunas saltam aos olhos: um requisito sem teste, ou um elemento de projeto que não serve a nenhum requisito. Quando a revisão trimestral aposentou uma pergunta sobre um agente regional, a tabela mostrou duas fontes de enriquecimento que existiam só para ela, e ambas foram abandonadas depois.
Nota de prática — Revisões de requisitos
Os requisitos são revistos com as partes interessadas que são donas deles. O líder do SOC aprova os prazos, o encarregado de privacidade a minimização, o engenheiro de OT as etapas de aprovação. Um requisito sem dono é candidato à exclusão.
Exemplo resolvido
Kofi converte o PIR sobre fornecedores de OT em quatro requisitos e escreve um teste para cada um, como "Dado um aviso sintético que nomeia o fornecedor V, o Lantern emite um alerta ao canal de OT em até 15 minutos."
Caso sintético. O fornecedor V, seu aviso e o prazo de 15 minutos são inventados.
Erros e limites
Requisitos que copiam as funcionalidades do produto de um fornecedor não são necessidades das partes interessadas. PIRs demais significam que nenhum é prioridade.
Exercícios
- EX061 — Reescrita verificável. Reescreva "O Lantern deve compartilhar rapidamente com os parceiros" como requisito verificável. Rubrica: 3 = métrica, limiar, escopo, percentual/prazo; 2 = só a métrica; 1 = inalterado; 0 = nenhuma.
- EX062 — Derivação de PIR. Derive um requisito de sistema de "Quais adversários miram distribuidoras regionais?" Rubrica: 3 = declaração específica com "deve" (p. ex., marcar/relatar agente que mira o setor) com verificação; 2 = vago; 1 = sem relação; 0 = nenhuma.
- EX063 — Requisito de privacidade. Escreva um requisito de privacidade para o módulo de OSINT do Lantern. Rubrica: 3 = proibição/limite verificável (nenhum perfil social pessoal; só fontes organizacionais) + teste; 2 = declaração sem teste; 1 = vago; 0 = nenhuma.
Síntese
Pergunte aos tomadores de decisão, derive "deves" verificáveis, inclua as necessidades não funcionais e rastreie tudo.
Continue estudando — capítulo 21 de 50
← Capítulo 20 (rascunho) · Índice de capítulos do curso · Capítulo 22 (rascunho) →