Capítulo 27 — Infraestrutura crítica e segurança setorial: verificação | Graduação Segurança de infraestrutura crítica e setores

Ensino gratuito e aberto para quem deseja proteger pessoas e tecnologias. Não é preciso criar uma conta para estudar ou consultar as respostas.

Mapa da aula

Aula 27 publicada. Mapa, exemplo, EX053.

flowchart TD
  N0["27.1 Verificação e validação"]
  N1["27.2 Tipos de teste"]
  N2["27.3 Avaliar detectores"]
  N3["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3
  N3 --> EX["Exemplo resolvido"]
  EX --> Q["Exercício EX053"]

Desenho lógico

flowchart LR
  N0["27.1 Verificação e validação"]
  N1["27.2 Tipos de teste"]
  N2["27.3 Avaliar detectores"]
  N3["Síntese do capítulo"]
  N0 --> N1 --> N2 --> N3 --> Q["EX053"]

[27.1 Verificação e validação]
    |
    v
[27.2 Tipos de teste]
    |
    v
[27.3 Avaliar detectores]
    |
    v
[Síntese do capítulo]
    |
    v
[Exemplo resolvido] --> [Exercício EX053]

Objetivos de aprendizagem e conexão

Depois deste capítulo, você consegue (1) distinguir a verificação ("construído certo") da validação ("construída a coisa certa") para controles de segurança; (2) projetar um teste capaz de mostrar que um controle não funciona; (3) avaliar um detector com precisão e revocação e escolher um limiar com trade-offs explícitos; e (4) reportar os resultados de verificação com as suas condições e limites. O capítulo se apoia nos Capítulos 8, 12, 15 e 24 e prepara o Capítulo 29 (operações) e o Laboratório II (Capítulo 30).

27.1 Verificação e validação

A verificação confere se um controle faz o que a sua especificação diz: o firewall bloqueia a porta 3389 do corporativo para o controle; o validador de setpoint rejeita NaN. A validação confere se o controle alcança a sua finalidade no ambiente real: os usuários corporativos não conseguem alcançar os sistemas de controle por nenhum caminho; os operadores não conseguem enviar setpoints inseguros. Um controle pode passar na verificação e falhar na validação (a regra do firewall funciona, mas um notebook de engenharia dual-homed a contorna). Uma boa verificação é falseável: ela é projetada de modo que um controle quebrado falharia no teste. Um teste que passaria quer o controle funcione, quer não, não prova nada.

27.2 Tipos de teste

A revisão de configuração compara as configurações com uma linha de base. Os testes funcionais exercitam o controle com entradas esperadas e proibidas (os testes de limite do Capítulo 8). Os testes de fluxo confirmam que os caminhos não permitidos estão bloqueados (Capítulo 7, sob autorização). Os exercícios de restauração verificam os controles de recuperação de ponta a ponta (Capítulo 15). Os testes de detecção reproduzem atividade sintética rotulada ou benigna-mas-suspeita para ver se o monitoramento alerta. Na TO, testar no processo em operação é restrito; use bancadas de teste, réplicas offline ou janelas planejadas acordadas com a operação.

Para a regra corporativo–controle da CW, um teste de fluxo a partir de um host corporativo autorizado para endereços do controle, numa janela planejada, é funcional; uma revisão de configuração sozinha não é.

27.3 Avaliar detectores

Um detector produz notas; um limiar as transforma em alertas. Compare os alertas com os rótulos de verdade: verdadeiros positivos (TP), falsos positivos (FP), falsos negativos (FN). Precisão = TP/(TP+FP): dos alertas, quantos eram reais? Revocação = TP/(TP+FN): dos eventos reais, quantos foram pegos? Elevar o limiar costuma aumentar a precisão e diminuir a revocação. Com eventos maliciosos raros (a taxa de base do Capítulo 12), a precisão pode ser ruim mesmo com taxas de erro por evento excelentes. Escolha um limiar perguntando quanto cada perda e cada alarme falso custam ao serviço — e lembre-se de que os dados rotulados de avaliação raramente correspondem às condições reais (Arp et al., 2022).

27.4 Exemplo resolvido e Laboratório 10 (sintético)

Este caso é sintético. A Calder Mutual avalia um detector de anomalias em 5.025 eventos rotulados, 25 deles maliciosos (semente 10).

# Lab 10 - detection evaluation on a labelled synthetic event set (offline)
import random
random.seed(10)
events = []  # (score from a detector, truly malicious?)
for _ in range(5000):
    events.append((random.gauss(0.30, 0.12), False))
for _ in range(25):
    events.append((random.gauss(0.70, 0.15), True))
for thr in (0.5, 0.6, 0.7):
    tp = sum(1 for s, m in events if s >= thr and m)
    fp = sum(1 for s, m in events if s >= thr and not m)
    fn = sum(1 for s, m in events if s < thr and m)
    prec = tp / (tp + fp) if tp + fp else 0
    print(f"threshold {thr}: TP={tp:2} FP={fp:3} FN={fn:2} precision={prec:.2f} recall={tp/(tp+fn):.2f}")

Saída esperada:

threshold 0.5: TP=23 FP=215 FN= 2 precision=0.10 recall=0.92
threshold 0.6: TP=20 FP= 36 FN= 5 precision=0.36 recall=0.80
threshold 0.7: TP=18 FP=  2 FN= 7 precision=0.90 recall=0.72

Em 0,5, a equipe pega 23 de 25, mas precisa vasculhar 215 alertas falsos; em 0,7, quase todo alerta é real, mas 7 ataques passam despercebidos. Nenhum dos dois é "correto". Uma escolha defensável poderia usar 0,7 para acionar o analista de plantão e 0,5 para uma fila de revisão diária — dois limiares para dois custos. O relatório declara as condições: notas sintéticas, uma única semente, 25 positivos (então as estimativas de revocação são grosseiras — Capítulo 37) e semelhança desconhecida com o tráfego real.

27.5 Erros comuns e limites

Testes que não podem falhar.
Reportar a acurácia em dados desbalanceados (99,5% de "acurácia" aqui, sem nunca alertar).
Escolher limiares sem declarar os custos.
Avaliar em dados que se parecem mais com os dados de treinamento do que com a realidade.
Verificar em laboratório e alegar validação em produção.

O Laboratório 10 mostra numericamente o segundo erro: nunca alertar dá 99,5 % de acurácia. Escolher 0,5 ou 0,7 sem dizer quanto custam um ataque perdido ou 215 alertas falsos a mais é o terceiro. Uma regra de firewall testada só a partir da réplica do laboratório é o quinto. Um teste que reportaria "bloqueado" porque o host de teste estava desligado é o primeiro.

Exercícios — capítulo 27

EX053 — Torne-o falseável. Objetivo: projetar um teste significativo. Entradas: a afirmação "o firewall da CW impede os usuários corporativos de alcançar a zona de controle". Etapas: projete um teste de verificação e um de validação, cada um com um resultado que mostraria que a afirmação é falsa, e a autorização necessária. Evidência esperada: dois projetos de teste. Rubrica: 3 = teste no nível da regra, a partir de um host corporativo para os endereços do controle em todas as portas, numa janela planejada, mais uma validação procurando caminhos alternativos (hosts dual-homed, acesso remoto, sem fio) por revisão de configuração e de fluxos; autorização declarada; 2 = um teste; 1 = não falseável; 0 = nada.

EX054 — A armadilha da acurácia. Objetivo: ver por que a acurácia engana. Entradas: Laboratório 10. Etapas: calcule a acurácia para o limiar 0,7 e para um detector que nunca alerta; explique por que os dois parecem "excelentes". Evidência esperada: dois números e explicação. Rubrica: 3 = (5025−2−7)/5025 ≈ 0,9982 e 5000/5025 ≈ 0,9950; explica o desbalanceamento de classes e recomenda precisão/revocação; 2 = só os números; 1 = um número; 0 = nada.

Síntese do capítulo

A verificação pergunta se um controle funciona como especificado; a validação pergunta se ele alcança a sua finalidade. Projete testes que possam falhar, avalie os detectores com precisão e revocação em limiares escolhidos por custos declarados e reporte as condições e os limites junto com os números.