Capítulo 19 — Infraestrutura crítica e segurança setorial: monitoramento
Mapa da aula
Aula 19 publicada. Mapa, exemplo, EX055.
flowchart TD
N0["19.1 De onde vêm as regras"]
N1["19.2 A ausência é um sinal"]
N2["19.3 Eventos, episódios e qualidade dos alertas"]
N3["19.4 Encaminhamento e primeira ação"]
N4["19.5 Monitorar o monitoramento"]
N5["19.7 Atividade prática: regras sobre eventos"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6
N6 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX055"]
Desenho lógico
flowchart LR
N0["19.1 De onde vêm as regras"]
N1["19.2 A ausência é um sinal"]
N2["19.3 Eventos, episódios e qualidade dos alertas"]
N3["19.4 Encaminhamento e primeira ação"]
N4["19.5 Monitorar o monitoramento"]
N5["19.7 Atividade prática: regras sobre eventos"]
N6["Síntese do capítulo"]
N0 --> N1 --> N2 --> N3 --> N4 --> N5 --> N6 --> Q["EX055"]
[19.1 De onde vêm as regras]
|
v
[19.2 A ausência é um sinal]
|
v
[19.3 Eventos, episódios e qualidade dos alertas]
|
v
[19.4 Encaminhamento e primeira ação]
|
v
[19.5 Monitorar o monitoramento]
|
v
[19.7 Atividade prática: regras sobre eventos]
|
v
[Síntese do capítulo]
|
v
[Exemplo resolvido] --> [Exercício EX055]
Objetivos de aprendizagem e conexão
Depois deste capítulo, você deve ser capaz de:
- escrever regras de detecção a partir de cenários e da arquitetura declarada;
- detectar a ausência — heartbeats que faltam, fontes silenciosas — assim como a presença;
- ajustar as regras para alertar uma vez por episódio, e não por evento, sem perder informação;
- monitorar o monitoramento: saber quando uma regra, uma fonte ou um encaminhador parou de funcionar.
O Capítulo 17 produziu logs normalizados. Este capítulo os transforma em alertas sobre os quais uma pessoa de plantão consegue agir. O objetivo não são muitos alertas; são os poucos certos, cada um apontando para um cenário e uma primeira ação.
19.1 De onde vêm as regras
Três fontes produzem as regras do LANTERN. Cenários (Capítulo 13): cada passo de um caminho que deixa rastro é uma regra candidata — login do fornecedor fora de uma janela aprovada, cloro fora da sua faixa. Arquitetura (Capítulos 2 e 8): qualquer fluxo que viole um conduíte declarado — corporativo para estação numa porta industrial — é uma regra que não precisa de inteligência de ameaças, porque é definida pelo seu próprio projeto. Comportamentos conhecidos: logins malsucedidos repetidos a partir de uma mesma origem valem ser conhecidos. A matriz ATT&CK for ICS da MITRE cataloga comportamentos de adversários observados contra sistemas industriais e ajuda a conferir se as regras cobrem as técnicas mais relevantes para os seus cenários (MITRE ATT&CK for ICS).
19.2 A ausência é um sinal
Nos serviços críticos, muitos dos alertas mais importantes são sobre coisas que param de acontecer: uma estação que para de reportar, um relay que para de encaminhar, uma fonte de logs que fica em silêncio, um backup que não roda. As regras de ausência precisam de um ritmo esperado (um heartbeat a cada cinco minutos) e de uma tolerância (alertar depois de 15 minutos de silêncio). Elas pegam interrupções, dispositivos com defeito, cabos cortados, configurações erradas — e atacantes que desabilitam os logs.
A Regra C sinalizou o silêncio de 40 minutos da PS-09 às 23:00, 15 minutos depois do seu último heartbeat; essa tolerância de 15 minutos é a escolha de projeto.
19.3 Eventos, episódios e qualidade dos alertas
Uma regra que dispara para cada evento correspondente inunda o tecnólogo de plantão: 14 logins malsucedidos viram 14 alertas. Regras melhores alertam uma vez por episódio — o primeiro evento numa janela, com uma contagem dos demais — e anexam contexto: zona de origem, criticidade do ativo, eventos recentes relacionados. Acompanhe a taxa de alarmes falsos e o tempo de resposta de cada regra. Uma regra que disparou cem vezes sem um verdadeiro positivo está treinando as pessoas a ignorá-la; ajuste-a, mude o seu limiar ou encaminhe-a para um relatório diário em vez de um acionamento.
19.4 Encaminhamento e primeira ação
Todo alerta precisa de um responsável e de uma primeira ação escrita na regra: "Modbus corporativo→estação: conferir se há uma sessão de engenharia aprovada em andamento (calendário de mudanças); se não houver, ligar para a sala de controle da Água e depois preservar os registros de fluxo." Os alertas que afetam o processo físico vão para a operação de Água, além da FSTS. Escreva as primeiras ações antes de ligar uma regra.
A primeira ação da Regra B cumpriu o seu papel na noite do exemplo resolvido: primeiro o calendário de mudanças, depois a sala de controle da Água.
A primeira ação da Regra C, depois do estudo do Capítulo 24, é "ligar para a sala de controle da Água, depois conferir a situação da operadora".
19.5 Monitorar o monitoramento
Regras, fontes e encaminhadores falham em silêncio. Monitore: a taxa de eventos de cada fonte (uma regra de ausência para os logs); a contagem de não interpretadas do normalizador (Capítulo 17); o horário da última avaliação de cada regra; e eventos de teste periódicos que deveriam produzir alertas conhecidos (Capítulo 23). A orientação do NIST sobre monitoramento contínuo de segurança da informação enfatiza a consciência contínua de se os controles continuam eficazes (NIST SP 800-137).
As falhas da Regra B no Laboratório 23, fluxos de um switch de estação que nunca foram exportados para o SIEM, mostram o custo de não monitorar as fontes: a regra estava certa, a sua entrada é que faltava.
19.6 Exemplo resolvido: uma noite, três regras (sintético)
O Laboratório 19 aplica três regras a uma noite de eventos e heartbeats. A Regra A (≥10 logins malsucedidos a partir de uma origem em 5 minutos) dispara uma vez para 192.0.2.44. A Regra B (Modbus corporativo→estação) dispara duas vezes para a mesma estação de trabalho, às 22:16 e às 22:31 — dois acionamentos para um episódio; ela deveria ser ajustada para alertar uma vez e atualizar uma contagem. A Regra C (heartbeat ausente por > 15 minutos) dispara às 23:00 para a PS-09, que ficou em silêncio por 40 minutos. Note o que não dispara: um único login malsucedido de e.strand a partir de um endereço interno, abaixo do limiar da Regra A — corretamente, já que uma senha digitada errado não é um episódio.
Junto com a linha do tempo do Capítulo 17, a Regra B é o alerta que mais importa: a estação de trabalho que fez login como administrador às 22:14 depois conversou em Modbus com um CLP. Primeira ação: conferir o calendário de mudanças; se nenhuma sessão de engenharia foi aprovada, ligar para a sala de controle da Água.
19.7 Atividade prática: regras sobre eventos
Laboratório 19 (salve como lab19.py, execute com python3 lab19.py):
# Lab 19 - three monitoring rules over normalized events, including "absence" (offline, standard library only)
# Synthetic events for one night at Fallowmere (times are minutes after 22:00 UTC).
events = [ # minute, host, type, fields
(14, "rly-01", "auth_ok", {"src": "10.40.3.7", "user": "b.lind"}),
*[(15 + i // 4, "rly-01", "auth_fail", {"src": "192.0.2.44", "user": "root"}) for i in range(14)],
(16, "fw-hub", "flow", {"src": "10.40.3.7", "dst": "10.20.0.11", "dport": 502}),
(31, "fw-hub", "flow", {"src": "10.40.3.7", "dst": "10.20.0.11", "dport": 502}),
(44, "rly-01", "auth_fail", {"src": "10.40.9.9", "user": "e.strand"}),
]
heartbeats = {"PS-04": list(range(0, 120, 5)), "PS-07": list(range(0, 120, 5)),
"PS-09": [m for m in range(0, 120, 5) if not 50 <= m < 85]}
alerts = []
# Rule A: >=10 failed logins from one source within 5 minutes
fails = [(m, f["src"]) for m, h, t, f in events if t == "auth_fail"]
for src in {s for _, s in fails}:
times = sorted(m for m, s in fails if s == src)
for i in range(len(times)):
if sum(1 for t in times if times[i] <= t < times[i] + 5) >= 10:
alerts.append((times[i], "A brute-force", src)); break
# Rule B: any flow from corp to a station on an industrial port (not a declared conduit)
for m, h, t, f in events:
if t == "flow" and f["src"].startswith("10.40.") and f["dst"].startswith("10.20.") and f["dport"] == 502:
alerts.append((m, "B corp->station Modbus", f"{f['src']}->{f['dst']}"))
# Rule C: heartbeat missing for > 15 minutes (silence is a signal)
for st, beats in heartbeats.items():
for a, b in zip(beats, beats[1:]):
if b - a > 15:
alerts.append((a + 15, "C station silent", f"{st} gap {b - a} min"))
for m, rule, detail in sorted(alerts):
print(f"22:{m:02d}+ {rule:<24} {detail}" if m < 60 else f"23:{m-60:02d}+ {rule:<24} {detail}")
print("alerts:", len(alerts), "| rule B fired per event, not per episode:", sum(1 for a in alerts if a[1].startswith("B")))
Saída esperada (Python 3.13.5):
22:15+ A brute-force 192.0.2.44
22:16+ B corp->station Modbus 10.40.3.7->10.20.0.11
22:31+ B corp->station Modbus 10.40.3.7->10.20.0.11
23:00+ C station silent PS-09 gap 40 min
alerts: 4 | rule B fired per event, not per episode: 2
Conte os alertas por episódio, e não por linha: os quatro alertas da saída são três episódios (Regra A para 192.0.2.44, Regra B para a estação de trabalho 10.40.3.7, Regra C para PS-09), e ajustar a Regra B para alertar uma vez e atualizar uma contagem os reduz a três. Confira também o que fica em silêncio: o único login falho de e.strand a partir de 10.40.9.9 fica abaixo do limiar da Regra A, corretamente, pois uma senha digitada errada uma vez não é um episódio.
19.8 Erros comuns e limites
- Regras sem cenário, responsável ou primeira ação.
- Apenas regras de presença; nada nota o silêncio.
- Um alerta por evento, inundando os respondedores.
- Limiares nunca revistos.
- Presumir que uma regra funciona porque foi implantada; ela precisa ser testada (Capítulo 23).
- Enviar alertas relevantes para o processo apenas à TI.
As regras detectam o que foi previsto. O comportamento imprevisto precisa de pessoas que olhem os dados — caça a ameaças, revisões — e de regras de ausência, que pegam efeitos sem conhecer as causas.
Os dois acionamentos da Regra B para um episódio, na noite do exemplo resolvido, são o terceiro erro.
Exercícios — capítulo 19
EX055 — Regra por episódio. Objetivo: reduzir o ruído dos alertas sem perder informação. Entradas: Laboratório 19. Restrições: apenas a biblioteca padrão. Etapas: (1) mude a Regra B para que ela gere um alerta por par origem–destino a cada 60 minutos, registrando a contagem de eventos correspondentes; (2) execute e mostre a saída; (3) explique qual informação é preservada. Evidência esperada: código, saída, explicação. Rubrica: 3 = um alerta da Regra B com contagem 2 e horários do primeiro e do último; explicação de que as contagens e os horários são preservados para a investigação enquanto o acionamento dispara uma vez; 2 = funciona, falta a contagem; 1 = não executado; 0 = nada.
EX056 — Primeiras ações. Objetivo: escrever alertas acionáveis. Entradas: Regras A, B e C. Restrições: no máximo três passos cada; precisa incluir para quem ligar. Etapas: escreva a primeira ação de cada uma. Evidência esperada: três procedimentos curtos. Rubrica: 3 = A: confirmar a exposição do SSH, conferir se houve algum sucesso a partir daquela origem, bloquear na borda sob mudança padrão; B: conferir o calendário de mudanças, ligar para a sala de controle da Água se não aprovado, preservar os fluxos; C: ligar para a sala de controle da Água para confirmar o estado da estação, conferir a situação da operadora, conferir nos logs do relay se há falhas de MAC; 2 = uma fraca; 1 = genérico; 0 = nada.
EX057 — Monitore o monitor. Objetivo: projetar o automonitoramento. Entradas: o pipeline de monitoramento do LANTERN: fontes → encaminhador → normalizador → regras → acionamento. Restrições: uma verificação por etapa. Etapas: liste a verificação, o seu limiar e quem é alertado. Evidência esperada: tabela. Rubrica: 3 = ausência da taxa de eventos da fonte, fila/acúmulo do encaminhador, taxa de não interpretadas do normalizador, horário da última execução da regra, teste de acionamento (acionamento sintético agendado e confirmado); limiares e destinatários sensatos; 2 = quatro etapas; 1 = genérico; 0 = nada.
Síntese do capítulo
Derive as regras de cenários, da sua própria arquitetura e de comportamentos conhecidos; dê a cada uma um responsável e uma primeira ação. Detecte a ausência, assim como a presença. Alerte por episódio, com contagens e contexto, acompanhe os alarmes falsos e os tempos de resposta, e encaminhe os alertas relevantes para o processo à operação. Monitore o monitoramento, porque cada etapa dele pode falhar em silêncio.
Continue estudando — capítulo 19 de 30
← Capítulo 18 · Índice de capítulos do curso · Capítulo 20 →
Siga para a próxima lição escrita.