Capítulo 19 — Arquitetura e engenharia de segurança: monitoramento
Mapa da aula
Aula 19 publicada. Mapa, exemplo, EX055.
flowchart TD
N0["19.1 O que registrar"]
N1["Laboratório — Regras de alerta simples sobre um dia"]
N2["19.2 Regras de alerta"]
N3["19.3 Revisão semanal"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4
N4 --> EX["Exemplo resolvido"]
EX --> Q["Exercício EX055"]
Desenho lógico
flowchart LR
N0["19.1 O que registrar"]
N1["Laboratório — Regras de alerta simples sobre um dia"]
N2["19.2 Regras de alerta"]
N3["19.3 Revisão semanal"]
N4["Síntese"]
N0 --> N1 --> N2 --> N3 --> N4 --> Q["EX055"]
[19.1 O que registrar]
|
v
[Laboratório — Regras de alerta simples sobre um dia]
|
v
[19.2 Regras de alerta]
|
v
[19.3 Revisão semanal]
|
v
[Síntese]
|
v
[Exemplo resolvido] --> [Exercício EX055]
Objetivos de aprendizagem
Você vai (1) escolher o que registrar em log e sobre o que alertar; (2) escrever regras de alerta simples; (3) conduzir uma rotina semanal de revisão.
19.1 O que registrar
Tomás decide quais eventos importam: logins no serviço de rastreamento e no portal, ações de administradores, sessões de suporte do fornecedor, mudanças de firewall, resultados de backup e sinalizações da validação de manifestos. Ele evita coletar tudo, porque uma equipe pequena não consegue revisar tudo e o armazenamento custa dinheiro. Cada fonte de log é ligada a um cenário de risco. Ele confere se os relógios dos dispositivos estão sincronizados, já que eventos com horários errados são difíceis de correlacionar ao investigar um incidente em vários sistemas. Ele também define prazos de retenção para cada fonte, guardando a maioria dos logs por noventa dias e os resultados de backup por um ano, para que as investigações tenham histórico suficiente sem custos excessivos de armazenamento.
Laboratório — Regras de alerta simples sobre um dia de eventos
# Three alert rules over a synthetic day of events: (minute, kind, subject, detail)
events = [(480 + i, "signin_fail", "r-07", "") for i in range(0, 7)] + \
[(600, "signin_fail", "r-02", ""), (605, "signin_fail", "r-02", ""),
(130, "vendor_session", "conveyor", "unapproved"), (840, "vendor_session", "conveyor", "approved"),
(180, "backup", "routeplan", "fail"), (185, "backup", "files", "ok")]
alerts = []
fails = {}
for t, k, s, d in sorted(events):
if k == "signin_fail":
fails.setdefault(s, []).append(t)
recent = [x for x in fails[s] if t - x <= 10]
if len(recent) > 5 and not any(a[1] == s for a in alerts if a[0] == "signin"):
alerts.append(("signin", s, f"{len(recent)} failures by {t//60:02d}:{t%60:02d}"))
elif k == "vendor_session" and d != "approved":
alerts.append(("vendor", s, f"session at {t//60:02d}:{t%60:02d} without approval"))
elif k == "backup" and d == "fail":
alerts.append(("backup", s, "backup failed"))
for a in alerts: print("ALERT", *a)
print(f"{len(alerts)} alerts")
Execute com python3 lab_alerts.py. Saída verificada:
ALERT vendor conveyor session at 02:10 without approval
ALERT backup routeplan backup failed
ALERT signin r-07 6 failures by 08:05
3 alerts
19.2 Regras de alerta
Tomás escreve três regras: alertar quando houver mais de cinco falhas de login no portal para uma conta em dez minutos; alertar sobre qualquer sessão do fornecedor fora de uma janela aprovada; e alertar sobre um backup que falhou. O laboratório as executa sobre um dia sintético de eventos. Ele gera três alertas: uma rajada de falhas de login numa conta de varejista, uma sessão noturna do fornecedor sem aprovação e um backup que falhou. Ele investiga cada um nos dados sintéticos e escreve o que um respondente real deveria verificar primeiro.
19.3 Revisão semanal
Sam e Tomás definem uma revisão semanal de trinta minutos: alertas gerados, como cada um foi tratado, eventuais mudanças de regras e o status dos backups. Eles registram as decisões num log compartilhado. As regras que disparam com frequência demais são ajustadas; as que nunca disparam são testadas com um evento simulado, para garantir que ainda funcionam. Ruth observa que o monitoramento é uma rotina, e não um produto. Uma equipe pequena que revisa alguns bons alertas toda semana enxerga mais do que uma equipe grande soterrada em dashboards que ninguém lê.
Exemplo resolvido
Tomás escolhe fontes de log ligadas aos cenários, escreve três regras de alerta testadas sobre eventos sintéticos e define uma rotina semanal de revisão.
Caso sintético. Os eventos e as regras são sintéticos.
Erros e limites
Os limiares deixam passar ataques lentos. Relógios dessincronizados confundem as investigações.
Exercícios
-
EX055 — Sincronização dos relógios. Por que conferir os relógios dos dispositivos? Rubrica: 3 = eventos com horários errados são difíceis de correlacionar;; 2 = correlação;; 1 = vago;; 0 = nenhuma.
-
EX056 — Alertas do laboratório. Que três alertas o laboratório gerou? Rubrica: 3 = falhas de login de r-07, sessão noturna não aprovada do fornecedor, backup que falhou;; 2 = dois;; 1 = vago;; 0 = nenhuma.
-
EX057 — Regras silenciosas. O que eles fazem com as regras que nunca disparam? Rubrica: 3 = testam-nas com um evento simulado;; 2 = testar;; 1 = apagar;; 0 = nenhuma.
Síntese
O monitoramento é uma rotina semanal construída sobre alguns logs bem escolhidos e regras ajustadas e testadas.
Continue estudando — aula 19 (capítulo 19 de 30)
← Capítulo 18 · Índice das aulas · Capítulo 20 →
Continue para a próxima aula já escrita.