Capítulo 20 — Infraestrutura crítica e segurança setorial: resolução de problemas
Mapa da aula
Aula 20 publicada. Mapa, exemplo, EX058.
flowchart TD
N0["20.1 Um método"]
N1["20.2 Preserve antes de mudar"]
N2["20.3 Quando uma falha vira um incidente"]
N3["20.4 Dados ausentes: quatro causas comuns"]
N4["20.6 Atividade prática: discrimine as causas"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5
N5 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX058"]
Desenho lógico
flowchart LR
N0["20.1 Um método"]
N1["20.2 Preserve antes de mudar"]
N2["20.3 Quando uma falha vira um incidente"]
N3["20.4 Dados ausentes: quatro causas comuns"]
N4["20.6 Atividade prática: discrimine as causas"]
N5["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> Q["EX058"]
[20.1 Um método]
|
v
[20.2 Preserve antes de mudar]
|
v
[20.3 Quando uma falha vira um incidente]
|
v
[20.4 Dados ausentes: quatro causas comuns]
|
v
[20.6 Atividade prática: discrimine as causas]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX058]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você deve ser capaz de:
- seguir um método disciplinado de resolução de problemas que funcione quer a falha se revele técnica, humana ou maliciosa;
- preservar as evidências antes de mudar as coisas, e saber quando uma falha precisa virar um incidente;
- distinguir as causas comuns de "dados ausentes" — perda, atraso, erro de relógio, filtragem — usando os próprios dados;
- escrever um registro de problema curto que a próxima pessoa consiga usar.
A maior parte da vida profissional de um implementador é gasta com falhas. Nos serviços críticos, algumas falhas são ataques e alguns ataques parecem falhas; o método precisa funcionar para os dois sem atrasar os reparos comuns.
20.1 Um método
- Defina o sintoma com precisão: o que está errado, desde quando, para quem, medido como. "PS-07 e PS-09 mostram lacunas no painel desde cerca de 22:50" — e não "a telemetria está quebrada".
- Confira primeiro o impacto e a safety: alguém precisa agir sobre o processo físico agora? Diga à operação de Água no que ela pode e no que não pode confiar.
- Preserve antes de mudar: copie os logs, as configurações e as saídas relevantes, com os horários, antes de reiniciar ou reconfigurar qualquer coisa (veja "Preserve antes de mudar", abaixo).
- Liste hipóteses, incluindo pelo menos uma explicação não maliciosa e uma maliciosa, e qual evidência as distinguiria.
- Teste primeiro a hipótese discriminante mais barata, usando leituras antes de gravações.
- Mude uma coisa de cada vez, sob o tipo de mudança apropriado (Capítulo 14), registrando cada mudança.
- Verifique a correção contra o sintoma original, e observe se ele volta.
- Registre a causa, as evidências, as ações e os itens em aberto.
20.2 Preserve antes de mudar
Reiniciar um serviço limpa a sua memória, rotaciona os logs e pode destruir a única evidência do que aconteceu. As recomendações do NIST de resposta a incidentes enfatizam preservar as evidências e coordenar a resposta com a gestão de riscos da organização (NIST SP 800-61 Rev. 3). Para um implementador, a preservação costuma ser rápida: copiar os logs e a configuração do serviço, exportar os registros de fluxo e de alertas relevantes, anotar os processos em execução e as conexões de rede, calcular hashes do que foi copiado e anotar o horário. Se a falha afeta o processo físico, restaurar o serviço pode legitimamente vir primeiro — mas diga isso e registre o que se perdeu.
20.3 Quando uma falha vira um incidente
Escale para o processo de incidentes quando qualquer uma destas condições for verdadeira: evidência de acesso ou mudança não autorizados (uma diferença de configuração não aprovada, a conta de alguém que saiu sendo usada — Capítulo 7); um controle de segurança falhou de um modo que poderia ser explorado; dados podem ter ido para onde não deveriam (Capítulo 12); ou a causa não pode ser encontrada e uma causa maliciosa é plausível. Escalar não é uma acusação. Isso traz pessoas com autoridade e deveres diferentes, incluindo as obrigações de notificação do operador (Capítulo 10).
O login de c.mendes em 14 de setembro é o gatilho mais claro de Fallowmere.
20.4 Dados ausentes: quatro causas comuns
A telemetria ausente é o sintoma mais comum do LANTERN. Os próprios dados costumam discriminar entre as causas:
- Perdidos — os números de sequência têm lacunas (Capítulo 15): as mensagens nunca foram recebidas.
- Atrasados — sequência completa, mas o horário de recebimento muito atrás do horário da estação, muitas vezes depois de um problema na operadora.
- Erro de relógio — sequência completa e chegada pontual, mas os carimbos de tempo da estação deslocados por um valor constante; os dados são arquivados na janela de tempo errada, então um painel que consulta pelo horário da estação mostra uma lacuna.
- Filtrados — mensagens recebidas, mas rejeitadas ou quarentenadas (contagens de rejeição subindo no log do relay).
20.5 Exemplo resolvido: duas lacunas, duas causas (sintético)
Os operadores relatam lacunas no painel para a PS-07 e a PS-09. O Laboratório 20 examina doze números de sequência de cada estação. Faltam na PS-07 os números de sequência 5–8, com chegada pontual dos demais: os dados se perderam. A PS-09 tem todos os números de sequência e chega pontualmente pelo relógio do relay, mas os carimbos de tempo da estação estão cerca de 422 segundos atrasados: o seu relógio está errado, e a janela do painel perde todos os seus pontos. Os dois sintomas pareciam idênticos no painel; as causas e as correções são completamente diferentes.
Para a PS-09, a próxima pergunta é por que o relógio está errado: a estação perdeu o seu caminho NTP até o relay (uma mudança de conduíte? Capítulo 2), ou alguém mudou a configuração de hora da estação? A primeira é uma falha; a segunda pode ser um evento de segurança. Um deslocamento constante de cerca de sete minutos em todas as mensagens é incomum para uma deriva — a deriva é gradual. Preserve os logs de NTP do relay e a configuração do conduíte antes que alguém acerte o relógio.
Para a PS-07, a lacuna de quatro mensagens consecutivas poderia ser uma queda da operadora, uma reinicialização da estação ou rejeições do relay. Confira o log de rejeições do relay naqueles horários antes de ligar para a BayTel: se houve falhas de MAC na PS-07 naquele momento, a causa está no tratamento das chaves (Capítulo 18), e não na operadora.
20.6 Atividade prática: discrimine as causas
Laboratório 20 (salve como lab20.py, execute com python3 lab20.py):
# Lab 20 - troubleshooting "missing telemetry": sequence gaps versus clock skew (offline, standard library only)
# Synthetic historian extract: station, sequence number, station timestamp (s), relay receive time (s).
rows = {
"PS-04": [(s, 1000 + 10*s, 1000 + 10*s + 1) for s in range(1, 13)],
"PS-07": [(s, 1000 + 10*s, 1000 + 10*s + 1) for s in range(1, 13) if s not in (5, 6, 7, 8)],
"PS-09": [(s, 1000 + 10*s - 420, 1000 + 10*s + 2) for s in range(1, 13)],
}
for st, rs in rows.items():
seqs = [r[0] for r in rs]
missing = sorted(set(range(seqs[0], seqs[-1] + 1)) - set(seqs))
offsets = [recv - ts for _, ts, recv in rs]
avg = sum(offsets) / len(offsets)
dx = "data lost in transit or at source" if missing else ("clock skew: station clock behind by ~%d s; data present but filed in the wrong window" % round(avg) if abs(avg) > 60 else "healthy")
print(f"{st}: received {len(rs)}/{seqs[-1]-seqs[0]+1}, missing seq {missing or '-'}, mean recv-ts offset {avg:+.0f} s -> {dx}")
# A dashboard that queries by station timestamp for window [1050, 1130) would show:
for st, rs in rows.items():
print(st, "points in dashboard window:", sum(1 for _, ts, _ in rs if 1050 <= ts < 1130))
Saída esperada (Python 3.13.5):
PS-04: received 12/12, missing seq -, mean recv-ts offset +1 s -> healthy
PS-07: received 8/12, missing seq [5, 6, 7, 8], mean recv-ts offset +1 s -> data lost in transit or at source
PS-09: received 12/12, missing seq -, mean recv-ts offset +422 s -> clock skew: station clock behind by ~422 s; data present but filed in the wrong window
PS-04 points in dashboard window: 8
PS-07 points in dashboard window: 4
PS-09 points in dashboard window: 0
Olhe as colunas das duas estações lado a lado. Os números de sequência da PS-07 saltam de 4 para 9, então quatro mensagens nunca chegaram. Os números de sequência da PS-09 estão completos, mas os seus carimbos de tempo da estação ficam atrás dos horários de chegada do relay em cerca de 422 segundos em todas as mensagens. O primeiro caso é perda; o segundo é tempo. Depois escreva a próxima verificação para cada uma: o log de rejeições do relay e a situação da BayTel para a lacuna da PS-07, e o caminho NTP e a configuração de hora para a PS-09, preservados antes que alguém acerte o relógio.
20.7 Erros comuns e limites
- Reiniciar primeiro e investigar depois.
- Uma única hipótese, em geral a mais familiar.
- Várias mudanças de uma vez, de modo que ninguém sabe qual corrigiu — ou qual quebrou outra coisa.
- Tratar toda falha como ataque, ou nenhuma.
- "Corrigir" um relógio ou uma configuração antes de registrar como estava.
- Fechar o ticket sem um registro da causa e das evidências.
Acertar primeiro o relógio da PS-09 teria destruído as evidências para a pergunta dos 422 segundos.
Ligar para a BayTel por causa da lacuna da PS-07 antes de conferir o log de rejeições do relay seria o segundo erro: uma única hipótese, a mais familiar, testada primeiro e possivelmente sozinha.
Exercícios — capítulo 20
EX058 — Hipóteses e discriminantes. Objetivo: raciocinar antes de agir. Entradas: sintoma: "a contagem de rejeições do relay para a PS-04 subiu de 0 para 300 por hora às 09:00; o painel não mostra dados da PS-04 desde então." Restrições: quatro hipóteses, pelo menos uma maliciosa. Etapas: para cada uma, dê a evidência que a apoiaria ou a descartaria, e a verificação mais barata. Evidência esperada: tabela. Rubrica: 3 = por exemplo, chave rotacionada na estação, mas não no relay (falhas de MAC nos motivos de rejeição, calendário de mudanças), salto do relógio da estação (rejeições pela janela), estado de reprodução envenenado (rejeições por reprodução depois de uma sequência alta — Capítulo 29), tráfego forjado (falhas de MAC a partir de um endereço de origem inesperado); as verificações são leituras; 2 = três; 1 = uma; 0 = nada.
EX059 — Lista de preservação. Objetivo: preservar evidências rapidamente. Entradas: o caso do deslocamento do relógio da PS-09. Restrições: no máximo dez minutos; nenhuma mudança nos sistemas. Etapas: liste o que você copiaria ou registraria, em ordem, e como você mostraria depois que as cópias não foram alteradas. Evidência esperada: lista. Rubrica: 3 = NTP do relay e logs do relay, configuração do conduíte/firewall e log de mudanças recentes, extrato do historiador, saída de uma análise no estilo do Laboratório 20, horário da coleta, hashes registrados no ticket e cópias guardadas fora do host; 2 = faltam os hashes ou os horários; 1 = "tirar uma captura de tela"; 0 = nada.
EX060 — Registro do problema. Objetivo: escrever um registro utilizável. Entradas: Capítulo 20 ("Exemplo resolvido: duas lacunas, duas causas"), e presuma que a causa da PS-09 foi uma mudança de firewall que bloqueou a udp/123 do relay para a estação dois dias antes. Restrições: no máximo 250 palavras; rótulos observado / inferido / feito / em aberto. Etapas: escreva o registro. Evidência esperada: o registro. Rubrica: 3 = sintoma preciso, evidências (deslocamento de ~422 s, sequência completa), causa com a mudança identificada, correção sob controle de mudanças, verificação e itens em aberto (por que a mudança removeu o NTP; por que nenhum alerta disparou para o deslocamento do relógio — acrescentar um); 2 = falta um elemento; 1 = só narrativa; 0 = nada.
Síntese do capítulo
Resolva problemas com um método: sintoma preciso, safety e impacto primeiro, preservar antes de mudar, várias hipóteses incluindo uma maliciosa, a verificação discriminante mais barata primeiro, uma mudança de cada vez, verificar e registrar. Escale para um incidente quando as evidências sugerirem atividade não autorizada ou exposição. Para dados ausentes, os próprios dados — sequência, chegada, carimbos de tempo, contagens de rejeição — costumam distinguir perda, atraso, erro de relógio e filtragem.
Continue estudando — capítulo 20 de 30
← Capítulo 19 · Índice de capítulos do curso · Capítulo 21 →
Siga para a próxima lição escrita.