Capítulo 13 — Infraestrutura crítica e segurança setorial: resolução de problemas
Mapa da aula
Aula 13 publicada. Mapa, exemplo, EX049.
flowchart TD
N0["13.1 O método"]
N1["13.2 Da falha ao incidente"]
N2["13.4 Segundo caso: a mesa corporativa na KW-04"]
N3["13.5 O registro de resolução de problemas"]
N4["13.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX049"]
Desenho lógico
flowchart LR
N0["13.1 O método"]
N1["13.2 Da falha ao incidente"]
N2["13.4 Segundo caso: a mesa corporativa na KW-04"]
N3["13.5 O registro de resolução de problemas"]
N4["13.6 Atividade prática"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX049"]
[13.1 O método]
|
v
[13.2 Da falha ao incidente]
|
v
[13.4 Segundo caso: a mesa corporativa na KW-04]
|
v
[13.5 O registro de resolução de problemas]
|
v
[13.6 Atividade prática]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX049]
Objetivos de aprendizagem e conexão
Ao final deste capítulo, você deverá ser capaz de:
- aplicar um método estruturado de resolução de problemas — definir o sintoma, coletar observações somente de leitura, listar hipóteses, testar previsões, preservar e só então mudar;
- eliminar hipóteses comparando o que cada uma prevê com o que você observou, de um modo que outras pessoas possam conferir;
- reconhecer quando uma investigação de falha se torna um incidente de segurança, e o que preservar nesse momento;
- manter um registro de resolução de problemas que também seja evidência.
O Capítulo 8 descreveu sintomas; os Capítulos 7, 9 e 11 lhe deram observações. Este capítulo os reúne sob pressão de tempo, quando uma estação silenciou e os operadores a querem de volta.
13.1 O método
- Defina o sintoma com precisão: qual tag, desde quando (UTC), como foi detectado, o que ainda funciona.
- Colete observações somente de leitura em ordem de custo: a situação das outras estações; contadores do enlace e do roteador; logs do firewall; um teste de conexão TCP a partir da origem normal de varredura; uma leitura de protocolo; registros de configuração do dispositivo.
- Liste hipóteses — pelo menos uma comum e uma relevante para a segurança — antes de testar qualquer uma.
- Escreva as previsões de cada hipótese: o que você observaria se ela fosse verdadeira?
- Compare as previsões com as observações. Uma hipótese contrariada por uma observação confiável é refutada; uma coerente com todas elas permanece.
- Preserve tudo o que possa ser evidência antes de mudá-lo (Capítulo 5).
- Mude uma coisa, sob um registro de mudança, e verifique (Capítulo 11).
- Registre a causa, as evidências e o que a teria detectado mais cedo.
A disciplina de escrever as previsões antes de comparar é o que impede a primeira história plausível de virar a conclusão.
13.2 Da falha ao incidente
Um exercício de resolução de problemas se torna um possível incidente quando uma observação não é explicada por nenhuma atividade aprovada: uma sessão de configuração não aprovada, uma origem desconhecida, um arquivo alterado sem registro de mudança. Nesse ponto, pare de mudar as coisas, preserve (configuração, logs, registros de sessão) e passe adiante pelo processo de incidentes. As recomendações de resposta a incidentes do NIST situam essa decisão dentro da gestão de riscos mais ampla da organização (SP 800-61 Rev. 3). O trabalho do técnico não é decidir que um ataque aconteceu; é perceber que falta a explicação e manter as evidências intactas.
13.3 Exemplo resolvido: a KW-09 silencia (sintético)
Às 07:05Z de 12 de outubro, as leituras da KW-09 param de chegar; todas as outras estações estão bem. Você coleta observações somente de leitura por quinze minutos e lista cinco hipóteses.
Laboratório 13 (salve como lab13.py e execute com python3 lab13.py):
# Lab 13 - eliminate hypotheses for "KW-09 readings missing" (offline, standard library only)
# Synthetic observations collected read-only between 07:05 and 07:20Z on 2026-10-12.
observed = {
"rtu_ping": True, # RTU answers ICMP from the SCADA server
"tcp502_handshake": True, # TCP connect to 10.10.9.2:502 succeeds from SCADA server
"modbus_reply": "exception 2", # read of registers 0..3 returns illegal data address
"fw_denies": False, # no fw-01 denies for 10.10.9.2 in the window
"radio_errors": False, # cellular router CRC/error counters flat
"rtu_config_changed": True, # rtu-kw09 config session at 06:41Z (clock-corrected) by user eng
"change_ticket": False, # no approved change ticket for KW-09 today
"other_stations_ok": True,
}
hypotheses = { # what each hypothesis predicts we would observe
"H1 radio/link failure": {"rtu_ping": False, "tcp502_handshake": False, "radio_errors": True},
"H2 firewall change blocks polls": {"tcp502_handshake": False, "fw_denies": True},
"H3 SCADA server fault": {"other_stations_ok": False},
"H4 RTU register map changed": {"rtu_ping": True, "tcp502_handshake": True, "modbus_reply": "exception 2",
"rtu_config_changed": True},
"H5 RTU powered off": {"rtu_ping": False},
}
for h, pred in hypotheses.items():
clash = [k for k, v in pred.items() if observed[k] != v]
print(f"{h:<32} {'REFUTED by ' + ', '.join(clash) if clash else 'CONSISTENT with all observations'}")
print("unapproved RTU configuration session -> preserve RTU config and session logs, then treat as possible incident"
if observed["rtu_config_changed"] and not observed["change_ticket"] else "change was approved")
Saída esperada (Python 3.13.5):
H1 radio/link failure REFUTED by rtu_ping, tcp502_handshake, radio_errors
H2 firewall change blocks polls REFUTED by tcp502_handshake, fw_denies
H3 SCADA server fault REFUTED by other_stations_ok
H4 RTU register map changed CONSISTENT with all observations
H5 RTU powered off REFUTED by rtu_ping
unapproved RTU configuration session -> preserve RTU config and session logs, then treat as possible incident
Quatro hipóteses são refutadas por observações específicas: o enlace está ativo (ping, handshake, contadores de erro estáveis); o firewall não está negando; o servidor SCADA está varrendo outras estações com sucesso; a RTU está ligada. Uma continua coerente: o mapa de registradores da RTU mudou, de modo que as leituras do servidor SCADA agora atingem endereços que o dispositivo não tem mais — exceção 02, exatamente como no laboratório do Capítulo 12. E a RTU registrou uma sessão de configuração às 06:41Z (relógio corrigido), sem chamado de mudança.
Essa última observação transforma uma falha num possível incidente. As próximas etapas corretas são: preservar a exportação da configuração atual da RTU e o seu log de sessões, e os logs do host de salto e da estação de engenharia de 06:30–06:50Z; informar o gerente de plantão da Kestrel Water de que os valores da KW-09 estão indisponíveis (talvez seja preciso uma visita ao local para leituras manuais); abrir um registro de incidente. Restaurar a configuração anterior é a correção — mas só depois da preservação e com a concordância do líder do incidente.
13.4 Segundo caso: a mesa corporativa na KW-04
O Capítulo 10 deixou um item em aberto: o fw-01 nega o tráfego das mesas corporativas para as estações, mas uma captura na KW-04 mostrou escritas vindas de 10.30.3.7. Hipóteses: (a) o endereço de origem da captura foi traduzido por algum dispositivo; (b) existe outro caminho até a KW-04 que contorna o fw-01. Verificações somente de leitura: a exportação da configuração do roteador celular da KW-04 mostra um redirecionamento de porta (port-forward) de tcp/502 a partir do seu endereço privado do lado da operadora, e a rede privada da operadora também é alcançável a partir da VPN corporativa de acesso remoto. A hipótese (b) é coerente; o caminho foi instalado durante um comissionamento em 2024 e nunca removido. A lição é arquitetural (Capítulo 15): todo roteador de estação é uma fronteira potencial, e o modelo do Capítulo 6 precisa incluí-lo.
13.5 O registro de resolução de problemas
Escreva à medida que avança, em UTC, com os quatro rótulos: observado, inferido, feito, em aberto. Um bom registro permite que um colega que assume na troca de turno continue sem lhe perguntar nada, e permite que um investigador reconstrua depois o que foi mudado e quando. O Capítulo 16 dá um modelo; o Capítulo 18 o sela como evidência do projeto.
Inclua referências de evidência para cada observação, como o hash da exportação da configuração da RTU e o intervalo do log do host de salto. No Laboratório 18 o registro vira 05-troubleshooting-log.md, e o seu hash no manifesto é verificado como OK quando o pacote é conferido.
13.6 Atividade prática
Acrescente ao Laboratório 13 a hipótese H6, "o firmware da RTU travou num modo degradado", com as previsões que você acha que ela faz, e observe se as observações existentes a refutam. Se não refutarem, nomeie a única observação adicional, somente de leitura, que a refutaria.
Se as observações existentes não refutarem a H6, nomeie uma verificação adicional somente de leitura, como um diagnóstico do fornecedor que informe o estado do firmware, que a refutaria. Escreva as previsões antes de inventar a verificação, para que a nova observação tenha algo a contrariar. Mantenha a H6 na lista até que ela seja refutada ou que o processo de incidentes assuma.
13.7 Erros comuns e limites
- Tratar uma hipótese coerente como provada; ela está apenas ainda não refutada.
-
O Laboratório 13 compara valores previstos exatos; as observações reais têm incerteza, e uma única observação pouco confiável não deve refutar uma hipótese sozinha.
-
Reiniciar primeiro e destruir evidências voláteis.
- Parar na primeira hipótese que se encaixa em vez de testar as previsões frente a todas as observações.
- Chamar a H4, o mapa de registradores da RTU alterado, de causa antes que uma exportação de configuração a confirme; o Laboratório 13 só mostra que ela é coerente.
- Mudar várias coisas ao mesmo tempo, de modo que a correção não pode ser atribuída.
Exercícios — capítulo 13
EX049 — Previsões primeiro. Objetivo: praticar o método. Insumos: a lacuna de sete minutos da KW-05, do Capítulo 8. Passos: listar três hipóteses com as suas previsões para ping, handshake TCP, resposta Modbus, contadores do rádio e outras estações. Evidência esperada: uma tabela. Rubrica: 3 = pelo menos uma hipótese de enlace, uma de varredura/SCADA e uma relevante para a segurança, com previsões distintas, de modo que as observações possam separá-las; 2 = previsões sobrepostas; 1 = apenas hipóteses; 0 = nada.
EX050 — Acrescente a H6. Objetivo: estender o laboratório. Insumos: atividade 13.6. Passos: implementar e executar. Evidência esperada: código, saída e a observação extra. Rubrica: 3 = previsões plausíveis (por exemplo, ping verdadeiro, handshake verdadeiro, resposta com timeout ou exceção 04); reconhece que, se a H6 previr exceção 02, ela não é refutada, e propõe uma verificação somente de leitura, como a página de diagnóstico ou o contador de tempo ligado da RTU; 2 = executa, sem raciocínio; 1 = tentativa; 0 = nada.
EX051 — O momento do escalonamento. Objetivo: reconhecer quando parar e preservar. Insumos: o caso da KW-09. Passos: escrever a mensagem de escalonamento ao líder do incidente e a lista dos itens preservados, com horários. Evidência esperada: mensagem e lista. Rubrica: 3 = a mensagem declara os fatos observados e a sessão não explicada, separa a inferência, pede uma decisão sobre a restauração; os itens preservados incluem a exportação da configuração e o log de sessões da RTU, os logs do jump-01 e da eng-ws-15 para a janela e o próprio registro de resolução de problemas, cada um com hash; 2 = bom, mas sem hashes; 1 = "fomos hackeados"; 0 = nada.
EX052 — Feche o caminho da KW-04. Objetivo: corrigir o desvio encontrado na 13.4. Insumos: o redirecionamento de porta do roteador e a alcançabilidade pela VPN. Passos: propor a mudança, a sua etapa de preservação, os seus testes e o seu responsável. Evidência esperada: plano de mudança. Rubrica: 3 = preservar primeiro a configuração do roteador; remover o redirecionamento de porta; restringir a rede privada da operadora a partir da VPN corporativa; teste negativo a partir de um cliente VPN identificado e teste positivo da varredura do SCADA; verificar todos os outros roteadores de estação quanto ao mesmo padrão; responsável nomeado; 2 = correção sem a verificação ampla; 1 = apenas remover; 0 = nada.
Síntese do capítulo
Resolver problemas num serviço crítico é um método, não um palpite: defina o sintoma, observe somente lendo, escreva hipóteses com previsões, elimine-as pelas evidências, preserve, depois mude uma coisa e verifique. Quando uma observação não é explicada por uma atividade aprovada, a falha se tornou um possível incidente; pare, preserve e escalone. O registro que você mantém é, ao mesmo tempo, a passagem de turno e a evidência.
Continue estudando — capítulo 13 de 18
← Capítulo 12 · Índice de capítulos do curso · Capítulo 14 →
Siga para a próxima lição escrita.