Capítulo 11 — Infraestrutura crítica e segurança setorial: verificação
Mapa da aula
Aula 11 publicada. Mapa, exemplo, EX041.
flowchart TD
N0["11.1 Requisitos que podem ser testados"]
N1["11.2 Testes positivos e negativos"]
N2["11.3 Regras de evidência"]
N3["11.5 Verificação segura em redes de controle"]
N4["11.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX041"]
Desenho lógico
flowchart LR
N0["11.1 Requisitos que podem ser testados"]
N1["11.2 Testes positivos e negativos"]
N2["11.3 Regras de evidência"]
N3["11.5 Verificação segura em redes de controle"]
N4["11.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX041"]
[11.1 Requisitos que podem ser testados]
|
v
[11.2 Testes positivos e negativos]
|
v
[11.3 Regras de evidência]
|
v
[11.5 Verificação segura em redes de controle]
|
v
[11.6 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX041]
Objetivos de aprendizagem e conexão
Ao final deste capítulo, você deverá ser capaz de:
- escrever requisitos como afirmações testáveis e vincular cada um a pelo menos um teste (rastreabilidade);
- desenhar testes positivos (a função necessária continua funcionando) e testes negativos (a ação proibida falha) para toda mudança de controle;
- recusar-se a contar um teste sem evidência e relatar os requisitos como verificados, falhos ou não testados;
- verificar sem prejudicar o processo: testes pequenos, com escopo, em janelas combinadas.
O Capítulo 10 mudou a configuração. Uma mudança não termina quando é aplicada; termina quando se mostra que os seus requisitos se sustentam. Este capítulo torna essa demonstração sistemática.
11.1 Requisitos que podem ser testados
"O historiador está endurecido" não pode ser testado. "O SSH no hist-02 escuta apenas em 10.90.0.21" pode. Escreva cada requisito de modo que um teste nomeado, executado por outra pessoa, possa reprová-lo. Divida os requisitos compostos: "apenas o servidor SCADA e a estação de engenharia alcançam tcp/502 das estações" precisa de um teste positivo (o SCADA continua varrendo) e de um teste negativo (outro host do centro de controle é recusado).
O REQ-1 do Laboratório 11 passa nesta verificação: o SSH escutando apenas em 10.90.0.21 é algo que os testes T1 e T2 poderiam ter reprovado. O REQ-4 mostra a divisão na prática: T5 e T6 cobrem as suas metades negativa e positiva, e o requisito falha se qualquer uma delas falhar. Ponha os identificadores dos requisitos no registro de mudança antes de o trabalho começar.
11.2 Testes positivos e negativos
Os testes negativos mostram que um controle bloqueia o que deveria; os testes positivos mostram que ele não bloqueia o que as operações precisam. Uma mudança de firewall que passa em todos os testes negativos, mas para a coleta do historiador, falhou. Em ambientes de controle, os testes positivos importam tanto quanto os negativos: a disponibilidade costuma ser a primeira prioridade. O guia de testes do NIST discute o planejamento e a execução de testes técnicos (SP 800-115); as orientações de monitoramento contínuo enfatizam que a eficácia dos controles precisa ser demonstrada de novo ao longo do tempo, não presumida (SP 800-137).
11.3 Regras de evidência
Um teste só conta se tiver: um identificador, o requisito que verifica, o método, o horário, a pessoa, o resultado e um arquivo de evidência (Capítulo 5). Uma "apenas revisão de configuração" sem saída registrada é uma atividade útil, mas não é resultado de teste. Um requisito sem nenhum teste contado está não testado — nem verificado, nem falho. Relatar o não testado como verificado é a forma mais comum de a verificação enganar.
O Laboratório 11 aplica a regra ao T8, uma revisão de configuração do REQ-2 sem arquivo de evidência, que o script ignora. O REQ-6 do Laboratório 11 continua não testado até que alguém produza uma linha de negação vinda do coletor; relatá-lo como verificado porque a regra existe esconderia a lacuna. Mantenha os arquivos de evidência ao lado dos identificadores dos testes no registro de verificação.
11.4 Exemplo resolvido: verificar a CHG-2207 (sintético)
A CHG-2207 endureceu o SSH no hist-02 e deveria fechar o acesso corporativo ao centro de controle no fw-01. O registro de verificação:
Laboratório 11 (salve como lab11.py e execute com python3 lab11.py):
# Lab 11 - requirement-to-test traceability after a hardening change (offline, stdlib)
# Synthetic verification record for change CHG-2207 on HIST-02 and fw-01, 2026-10-12.
requirements = {
"REQ-1": "SSH listens only on management address 10.90.0.21",
"REQ-2": "Root cannot log in over SSH",
"REQ-3": "Corporate desks cannot reach control-centre RDP",
"REQ-4": "Only SCADA server and engineering workstation reach station tcp/502",
"REQ-5": "Historian still receives KW-01..KW-12 readings after change",
"REQ-6": "Firewall denies are logged to the collector",
}
tests = [ # test id, requirement, method, positive/negative, result, evidence
("T1", "REQ-1", "listening-socket listing on host", "neg", "pass", "ss-output-0612.txt"),
("T2", "REQ-1", "connect to 10.20.0.21:22 from jump host", "neg", "pass", "conn-0614.txt"),
("T3", "REQ-2", "root login attempt from jump host", "neg", "pass", "auth-0615.log"),
("T4", "REQ-3", "RDP connect from 10.30.3.7", "neg", "fail", "conn-0618.txt"),
("T5", "REQ-4", "Modbus read from 10.20.0.12", "neg", "fail", "conn-0620.txt"),
("T6", "REQ-4", "Modbus read from SCADA 10.20.0.10", "pos", "pass", "poll-0621.txt"),
("T7", "REQ-5", "count stations reporting 06:30-06:40Z", "pos", "pass", "hist-count.csv"),
("T8", "REQ-2", "config review only", "neg", "pass", ""),
]
status = {}
for tid, req, method, kind, res, ev in tests:
if not ev: print(f"{tid} {req} ignored: no evidence file recorded ({method})"); continue
status.setdefault(req, []).append((tid, kind, res))
for req, text in requirements.items():
rs = status.get(req, [])
if not rs: verdict = "UNTESTED"
elif any(r == "fail" for _, _, r in rs): verdict = "FAILED"
else: verdict = "verified"
kinds = "+".join(sorted({k for _, k, _ in rs})) or "-"
print(f"{req} {verdict:<9} tests={','.join(t for t, _, _ in rs) or '-':<6} kinds={kinds:<7} {text}")
v = sum(1 for r in requirements if status.get(r) and all(x[2] == "pass" for x in status[r]))
print(f"verified {v}/{len(requirements)}; the change is not complete until every requirement is verified")
Saída esperada (Python 3.13.5):
T8 REQ-2 ignored: no evidence file recorded (config review only)
REQ-1 verified tests=T1,T2 kinds=neg SSH listens only on management address 10.90.0.21
REQ-2 verified tests=T3 kinds=neg Root cannot log in over SSH
REQ-3 FAILED tests=T4 kinds=neg Corporate desks cannot reach control-centre RDP
REQ-4 FAILED tests=T5,T6 kinds=neg+pos Only SCADA server and engineering workstation reach station tcp/502
REQ-5 verified tests=T7 kinds=pos Historian still receives KW-01..KW-12 readings after change
REQ-6 UNTESTED tests=- kinds=- Firewall denies are logged to the collector
verified 3/6; the change is not complete until every requirement is verified
Três requisitos verificados, dois falhos, um não testado. O REQ-3 falhou porque a R4 foi deixada no lugar: o chamado dizia "consertar a regra de RDP", e o engenheiro corrigiu a R5, e não a regra que a sombreava — um padrão comum quando uma mudança é escrita como edição de linha, e não como requisito. O REQ-4 falhou no teste negativo (10.20.0.12 ainda consegue ler as estações, via R6), enquanto o teste positivo passou — exatamente por isso os dois tipos são necessários. O REQ-6 não tem teste algum; ninguém verificou se as negações chegam ao coletor, de modo que as detecções do Capítulo 17 ficariam cegas às tentativas negadas. O T8 foi ignorado porque não tem arquivo de evidência. A mudança volta para "em andamento" com três itens em aberto, cada um com um responsável.
11.5 Verificação segura em redes de controle
- Prefira ler resultados que o sistema já registra (logs de firewall, contagens do historiador) a gerar tráfego.
- Ao gerar tráfego, use uma origem de teste identificada (por exemplo, 10.30.99.9), a menor ação possível (uma conexão TCP sem carga) e uma janela combinada, com as operações informadas.
- Nunca verifique um bloqueio de escrita tentando escrever num controlador em produção; verifique-o com um teste de conexão e o log do firewall, ou frente a um dispositivo reserva num laboratório (Capítulo 12).
- Pare ao primeiro comportamento inesperado.
As operações devem saber, antes da primeira conexão, que 10.30.99.9 é a origem de teste, para que o seu tráfego não seja confundido com um intruso.
11.6 Atividade prática
Escreva um teste para o REQ-6 que não toque em nenhuma estação: uma tentativa de conexão da mesa de testes identificada para uma porta do centro de controle que deveria ser negada, seguida de uma consulta ao coletor pela linha de negação correspondente em até 60 s. Acrescente-o ao Laboratório 11 como T9, com um nome de arquivo de evidência, e execute de novo.
Use a mesa de testes identificada e depois consulte o coletor pela negação correspondente em até sessenta segundos. Acrescente o teste como T9, com um nome de arquivo de evidência, e execute de novo o Laboratório 11, para que o REQ-6 passe de não testado para verificado ou falho. Guarde o texto da consulta ao coletor no arquivo de evidência, para que o teste possa ser repetido.
11.7 Erros comuns e limites
- Executar apenas testes negativos e não perceber que a coleta do historiador parou.
- Contar um teste sem evidência.
- Relatar "5 de 6 testes passaram" em vez da situação de cada requisito.
- Verificar uma vez e presumir para sempre; verifique de novo depois de mudanças relacionadas.
-
O Laboratório 11 trata qualquer teste falho como requisito falho; um requisito também pode estar parcialmente verificado, se um teste cobrir só parte do seu escopo — diga isso com palavras.
-
Deixar o REQ-6 sem teste porque produzir uma linha de negação no coletor parecia mais difícil do que ler a regra do firewall.
Exercícios — capítulo 11
EX041 — Torne testável. Objetivo: reescrever requisitos. Insumos: "O acesso remoto é seguro", "O tempo está sincronizado", "Os logs são mantidos". Passos: reescrever cada um como um ou mais requisitos testáveis para o KVROC. Evidência esperada: requisitos reescritos, com uma ideia de teste para cada. Rubrica: 3 = afirmações específicas como "o acesso do fornecedor à SS-3 só é possível via jump-01, com MFA, durante uma janela habilitada", "todos os hosts da Z2 a menos de 1 s do ntp-ops", "os eventos de permissão e de negação do fw-01 chegam ao coletor em até 60 s e são retidos por 12 meses"; cada uma com um teste; 2 = um vago; 1 = reformulado; 0 = nada.
EX042 — Acrescente o teste que falta. Objetivo: fechar um requisito não testado. Insumos: o Laboratório 11 e a atividade da 11.6. Passos: acrescentar o T9 para o REQ-6 com resultado pass e arquivo de evidência collector-0630.txt; executar. Evidência esperada: saída. Rubrica: 3 = REQ-6 verificado via T9, total "verified 4/6"; explica que o REQ-3 e o REQ-4 continuam impedindo a conclusão; 2 = apenas a saída; 1 = tentativa; 0 = nada.
EX043 — Testes positivos para uma mudança de firewall. Objetivo: proteger a disponibilidade. Insumos: a correção do fw-01 do EX038. Passos: listar os testes positivos necessários antes de fechar a mudança. Evidência esperada: lista com método e evidência. Rubrica: 3 = o SCADA varre as doze estações (contagem do historiador), a estação de engenharia consegue se conectar a uma estação numa janela aprovada, o SSH do jump-01 para a Z2 funciona, a exportação diária do hist-02 continua chegando; cada um com a fonte da evidência; 2 = alguns; 1 = nenhum positivo; 0 = nada.
EX044 — Não testado não é verificado. Objetivo: relatar com honestidade. Insumos: o resumo de um gerente: "CHG-2207: 7 de 8 testes passaram, concluída". Passos: escrever a situação corrigida em um parágrafo. Evidência esperada: parágrafo. Rubrica: 3 = declara a situação por requisito (3 verificados, 2 falhos, 1 não testado), nomeia os itens em aberto e os responsáveis, diz que a mudança não está concluída; 2 = correto, mas sem responsáveis; 1 = edição menor; 0 = nada.
Síntese do capítulo
A verificação transforma uma mudança de configuração num resultado demonstrado. Escreva requisitos que possam falhar, teste cada um com testes positivos e negativos, conte apenas os testes com evidência e relate cada requisito como verificado, falho ou não testado. Em redes de controle, verifique com as menores ações com escopo, e nunca fazendo experiências no processo em produção.
Continue estudando — capítulo 11 de 18
← Capítulo 10 · Índice de capítulos do curso · Capítulo 12 →
Siga para a próxima lição escrita.